[Automation] Align embedded OpenCode runtime prompt with no-early-stop commercial loop

[seonghobae]

Gap

The external hourly mightyETL commercial scheduler has been strengthened to be explicitly work-conserving: every completed action/defer decision returns to a live executable queue, waiting is local, branch-writer conflicts are branch-local, and termination requires a mandatory second fresh sweep proving no safe work remains or genuine invocation-budget exhaustion.

PR #121's embedded .github/workflows/hourly-opencode-maintenance.yml runtime PROMPT, at exact head 75265fae9fcf5faac6f8b9cab63247ac86f23dd4, already has useful RCA → remediation feasibility → execute → reverify → fallback behavior, but its work-selection text still centers on exactly one source-actionable PR or exactly one independent vertical slice and does not explicitly require a post-action return to the queue plus double exit sweep. That leaves a future instruction-path drift risk once #121 becomes protected runtime.

Why this is not being patched directly into #121 now

#143 → #148 are repaired exact-predecessor stack items rooted on the unchanged #121 head. Advancing #121 solely to strengthen prompt wording would invalidate that exact predecessor boundary and force another non-destructive replacement/revalidation cascade through the durable-job stack. That ancestry churn has no independent product value while the external scheduler already enforces the stronger behavior today.

Therefore this issue is defer_until_trigger, not forgotten work.

Trigger

Execute immediately after either:

1. ci: schedule NVIDIA OpenCode maintenance agent #121 integrates into protected develop; or
2. a separate unavoidable ci: schedule NVIDIA OpenCode maintenance agent #121 source defect already requires advancing its head, in which case fold this test-first prompt alignment into that same necessary head movement before rebuilding downstream ancestry.

Do not modify #121 only to retrigger reviewers/checks.

Required runtime contract

The embedded OpenCode prompt/tests must explicitly require:

• action completion is intermediate state, not an invocation endpoint;
• after every remediation, commit, documentation update, test result, deferred blocker, or completed slice, return to the highest-value safe executable queue;
• one remote candidate publication limit constrains mutation output, not read-only diagnosis/testing/documentation analysis after a candidate is prepared;
• queued checks/reviews/provider waits are local deferred items, not reasons to idle;
• same-branch writer movement freezes that branch, not the whole repository;
• mandatory final fresh sweep of PRs/issues/checks/reviews/security/stack/docs/release/product gaps;
• perform another safe action and sweep again if any executable item exists;
• terminate only on genuine finite run-budget exhaustion or a second fresh sweep proving no remaining safe action;
• routine status narration is not work.

TDD

• first add/modify workflow contract tests that fail on the current ci: schedule NVIDIA OpenCode maintenance agent #121 prompt because the post-action requeue/double-exit language is absent;
• run the focused RED on the exact branch ancestry;
• change only the runtime prompt/authoritative agent guidance required for GREEN;
• preserve the current one-candidate deterministic publisher safety boundary unless a separate reviewed ADR intentionally changes it;
• rerun focused + full Maven tests and exact coverage;
• update doctoring/AGENTS/CLAUDE/CHANGELOG/ADR if the governing automation contract changes;
• regenerate all exact-head checks/reviews because old ci: schedule NVIDIA OpenCode maintenance agent #121 evidence does not transfer after any head movement.

Stack safety

If this is executed after #121 merges, start a fresh direct-develop PR and do not attach it beneath an obsolete pre-merge stack branch. If executed because #121 itself must move before merge, repair downstream exact ancestry non-destructively in dependency order and state explicitly that old checks/reviews/approvals do not transfer.

[seonghobae]

2026-08-10 scheduler incident RCA and trigger-safe prompt amendment

The user-facing scheduler repeatedly returned only There was a problem with your scheduled task. while the repository still had executable work. That generic message is control-plane symptom evidence, not evidence that mightyETL work was complete or that the repository caused the failure.

What is proven

• The previous loop voluntarily terminated after reporting one bounded action/documentation state while other mightyETL lanes remained executable.
• Prompt mutation and documentation assessment were repeatedly treated as terminal artifacts despite the intended work-conserving contract.
• Long, self-repeating scheduler text increases transport/context cost, while ABSOLUTE NO-EARLY-STOP without a clean finite-budget handoff can collide with the platform invocation boundary.
• The scheduler surface does not expose an internal exception, stack trace, or failing component here. Therefore prompt length, provider/runtime exhaustion, connector failure, and platform control-plane failure remain hypotheses rather than a fabricated single root cause.

Durable remediation contract

When issue #154 reaches its existing trigger, the embedded runtime prompt/tests must additionally require:

1. a generic scheduled-task/tool/provider failure blocks only that control-plane action and immediately hands back to the fresh repository queue;
2. stable product/architecture detail belongs in protected repository authority, keeping the scheduler concise instead of appending incident history;
3. a prompt edit receives zero completion credit and cannot be the final deliberate action when safe repository work exists;
4. after user redirection, perform at least two materially distinct safe repository actions when two execute-now lanes exist, including one non-documentation action whenever available;
5. use budget-safe continuation only from actual remaining-runtime/tool signals: do not start a RED test, branch, or multi-step mutation that cannot reach a verified or safely test-only state; leave no temporary writer machinery or knowingly broken non-test-only head;
6. budget continuation is not product completion and the next hourly invocation starts with a fresh whole-queue inventory;
7. any execute-now item found during an exit sweep resets the consecutive-sweep count.

Feasibility and stack decision

• execute_now on PR ci: schedule NVIDIA OpenCode maintenance agent #121 solely for this wording remains rejected: feat(etl): add lease-fenced durable job worker #143→feat(etl): replace replay on repaired cancellation stack #148 depend on its exact unchanged predecessor and unnecessary movement would invalidate their ancestry/evidence.
• defer_until_trigger remains realistic: fold the amendment into an unavoidable ci: schedule NVIDIA OpenCode maintenance agent #121 movement, or implement it on a fresh direct-develop branch after ci: schedule NVIDIA OpenCode maintenance agent #121 integrates.
• External scheduler repair is separate from protected runtime truth; this issue is the durable repository handoff and must not be represented as shipped automation.

This incident must not be closed merely because the external prompt was shortened. Acceptance still requires test-first embedded-runtime alignment, exact-head gates, independent review, protected integration, and protected-develop operational proof.