Mixed Ops Vs Repo Fix Plan Boundary

Mixed Ops vs Repo Fix Plan Boundary

Use when an issue blends two possibilities:

1. an operational/live-environment problem
2. a repo-owned code/config defect

Examples:

• cron job missing evidence logs
• scheduled task may be not installed vs installed-but-failing
• wrapper script may fail only under real shell/cron conditions

Core rule

Do not write a plan that assumes a code fix before proving whether the live problem is actually repo-owned.

The plan must first classify the live state, then branch:

• diagnosis-only / operator-guidance outcome
• repo-code remediation outcome

Required planning pattern

1. Capture a reviewable live-state artifact

Create a durable artifact under docs/reports/ showing the real live state. Examples:

• installed crontab probe
• current task status from live logs
• host-specific environment evidence

This artifact should eliminate at least one branch of ambiguity.

2. Narrow the failure branches explicitly

Write the remaining branches in the plan, for example:

• not installed
• installed but not firing
• installed and failing after launch

If one branch is already eliminated by evidence, say so explicitly.

3. Add an explicit stop condition

The plan must say:

• If hermetic reproduction does NOT show a repo-owned defect, stop at diagnosis + operator guidance.
• Do NOT pretend a repo patch solved the host problem.

4. Separate operator evidence from product behavior

Do not turn live host inspection into a fake unit test. Instead:

• treat live probes as reviewable artifacts / operator evidence
• keep repo tests focused on reproducible repo-owned behavior

5. Pick one owner for evidence/logging

When the issue involves multiple possible evidence sources, explicitly choose one source of truth. Example:

• wrapper-owned logging is canonical
• outer cron redirection removed to avoid double-write ambiguity

Avoid plans that leave logging ownership ambiguous.

6. Use hermetic shell reproduction for cron-like failures

If shell-ordering or cron environment is suspected:

• reproduce under /bin/sh, not just bash
• stub downstream dependencies
• test the exact generated command shape, not only fragments

7. Make acceptance criteria branch-aware

Acceptance criteria should distinguish:

• repo-owned failure reproduced and fixed
• operational-only classification recorded with no repo code changes

Good wording pattern

"If hermetic reproduction shows no repo-owned defect, this issue ends as diagnosis-only with operator guidance and no repo code changes. If hermetic reproduction confirms a repo-owned failure path, then the bounded fix is implemented."

Pitfalls

• Spending many iterations tightening a plan that still mixes diagnosis and remediation
• Treating operational probes as if they were stable CI tests
• Leaving two logging/evidence owners in place
• Claiming success after a repo patch when the live issue was really host drift
• Failing to capture the live-state artifact in a durable repo path

When to stop iterating

If repeated adversarial review still says the diagnosis-vs-remediation boundary is unclear after multiple tightening passes, stop forcing that issue forward. Switch to a different issue and return later with better evidence or a narrower scope.