@frankzhang2026/opencode-android-orchestrator 1.0.5 → 1.2.0

package/docs/QUEUE.md

@@ -1,6 +1,6 @@
 # Queue and background execution
 
-Version `1.0.5` stores proposals and approved contracts under
+Version `1.2.0` stores proposals and approved contracts under
 `<git-common-dir>/automation-runtime/inbox/queue.json`. A contract is runnable
 only after its full plan, version, digest, target branch and commit policy are
 approved and durably recorded. Planning reads a fixed `planningHead`, so another
@@ -33,7 +33,7 @@ local commit SHA, authorization source and `pushed: false` (未推送).
 | `inPlaceExclusive` (new-install default) | `humanApproval` (new-install default) | After acceptance, local integration and directory handoff, or approved abort |
 | `inPlaceExclusive` | `autoCommit` (configured default or explicitly sealed override) | After build, full tests, Review, local commit/integration and handoff |
 | `isolatedWorktree` | `humanApproval` | After the worker and its children exit and its result is safely sealed |
-| `isolatedWorktree` | `autoCommit` | Rejected; fresh compatible policy approval is required |
+| `isolatedWorktree` | `autoCommit` | V8 must explicitly authorize isolated auto integration; after verified local handoff, or safe sealing and confirmed exit on a pre-commit failure |
 
 Both workspaces use one execution slot per Git common directory. A retained
 isolated candidate keeps its own directory; revalidation and integration must
@@ -82,8 +82,18 @@ opencode-android-orchestrator queue stop .
 opencode-android-orchestrator queue start .
 ```
 
-An unsuccessful OpenCode agent process pauses consumption as a shared execution
-fault; inspect its log and fix provider/environment failures before clearing it.
+An unsuccessful OpenCode agent process retains its task's logs and stopped
+candidate. Its exit code alone does not establish a shared execution fault.
+In isolated mode, independent tasks can continue after sealing and confirmed
+process exit; dependent tasks still wait for successful local integration.
+Fixed mode continues to hold the directory until approved recovery or abort.
+Unknown ownership, incomplete repository leases and shared scheduler failures
+still block consumption. No automatic environment retry is implied.
+
+Reviewer interruption recovery uses the approved queue `resume-review` request
+and the one-argument Shell entry. It rechecks the sealed diff and does not rerun
+Coder. The orchestration step bound supports zero, one or two configured Review
+corrections, including a final budget-exhaustion state check.
 
 Pause stops new reservations until explicit resume or a new contract is
 successfully enqueued. Stop terminates the scheduler while preserving
@@ -124,7 +134,9 @@ It does not run `clean` or rerun all dependency tasks. Coder, Reviewer and local
 integration perform the configured full suite and build gates. Evidence records
 fresh-test logs, configured tasks and elapsed seconds.
 
-Newly generated contracts use task-contract schema V3. Every verification case
+The 1.2.0 templates generate task-contract schema V4 with verification
+version 2. The 1.0.5 package
+does not include this protocol. Every verification case
 has a stable ID, a one-based acceptance-criterion reference, an evidence source,
 an exact test identity, and a pre-change classification:
 
@@ -134,15 +146,71 @@ an exact test identity, and a pre-change classification:
 - `observe` may record a previously uncertain boundary, but a failure is
   accepted only when the contract declares its expected cause.
 
-Before product code changes, `record-red.sh TASK-ID` forces fresh focused Test
-execution and collects structured case results through a temporary Gradle init
-script. Missing, duplicate, skipped or undeclared cases, build failures, and any
-preserved behavior failure reject the preflight. Failed attempts remain under
-the task evidence directory; only a completely valid attempt creates immutable
-RED and test-manifest records. Those records bind the contract hash, execution
-baseline and test-only diff, so changing a RED test afterwards invalidates the
-quality gate. V1/V2 contracts already approved before upgrade retain the legacy
-explicit failure-text command.
+Planner declares only the task behavior cases. Before Coder edits any test,
+`claim-task.sh` captures every existing case in the approved focused scope.
+Fully qualified configured Gradle Test paths distinguish modules; overlapping
+filters are combined per task. Each parameter instance must have a distinct,
+stable `(taskPath, className, name)` identity. Ambiguous identities are rejected.
+
+The sealed contract explicitly includes:
+
+```json
+"inventory": {
+  "mode": "focusedBaseline",
+  "existingSkips": "reject",
+  "emptyBaseline": "reject"
+}
+```
+
+Use `existingSkips: preserve` only to preserve already skipped regression cases;
+it never permits a new skip or skipped behavior case. Use `emptyBaseline: allow`
+only for an intentionally empty task/filter scope, such as a new test class.
+An empty RED/GREEN is still rejected. Policies apply per task, not only to the
+combined result count. Baseline failures always block before test edits.
+
+`record-red.sh TASK-ID` runs the shared collector on unchanged production code.
+It combines the captured regression cases and approved behavior cases into one
+manifest. Missing/extra cases, new skips, ambiguous identities, unexpected
+failures, incomplete events and build failures cannot become RED. GREEN must
+cover the same manifest. No stale XML, cached Test result or discovery dry-run
+is accepted as an actual execution. JUnit XML and Gradle logs are retained with
+the run-bound event stream; the stream and its completion/count records drive
+the decision. See [Gradle Test](https://docs.gradle.org/9.4.1/dsl/org.gradle.api.tasks.testing.Test.html)
+for the underlying execution and listener APIs.
+
+Evidence binds the contract, configuration, original execution baseline,
+collector, full test/resource snapshot and attempt files. JVM source sets and
+Android test source providers discover custom inputs without expanding contract
+or agent edit permissions. Symlink, external and generated inputs fail with a
+specific unsupported-input reason. Test and resource inputs freeze after RED.
+The final check also binds GREEN to the verified HEAD and working files.
+Each GREEN invocation first invalidates the previous success in
+`green-verification.json`. Final checks require a PASSED marker bound to the
+same verification run and report digest; failed, interrupted or early-rejected
+reruns cannot reuse an older successful report.
+Human-owned commit-prefix and snapshotted worktree-allowlist files remain outside
+the evidence; changing the exclusion policy invalidates its binding. Such files
+cannot also be test inputs. An isolated candidate can revalidate an advanced
+production baseline, but incoming changes to frozen test inputs block it and
+require a newly approved task, not replacement of the original RED.
+
+Failed attempts remain under `inventory-attempts/`; only a complete valid RED
+is sealed. Queue details and `status.sh` expose `baselineInventory`,
+`testManifest`, `greenInventory` and `inventoryStatus` (queue details use the
+hyphenated file names). Status includes the phase, reason code, offending cases
+and next action. Acceptance reports include baseline/RED/GREEN coverage and
+the permitted skips. `processExitCode` is the actual Gradle status; for V4 the
+legacy `red.exitCode: 1` means `approved-case-failure`, because the collector
+allows Test tasks to complete and classifies failures itself. The reviewer must
+still check the semantic origin of the expected failure, beyond type/message.
+Structured errors carry the queue execution ID. Errors from older executions
+or malformed status sidecars do not replace the current script's failure.
+
+V1/V2 retain the legacy failure-text command. Existing V3 contracts retain their
+declared-case-only verification. New inventory coverage requires a V4 contract
+and fresh approval, not an in-place rewrite of old evidence. Upgrading templates
+and executor must be done together after the development build is versioned;
+same-version production installations remain verification-only.
 
 ## Baselines and recovery
 
@@ -173,8 +241,13 @@ exited; a heartbeat timeout alone never steals a live lock. Execution recovery
 also checks the whole worker process group. If a reservation has no registered
 worker, stop its recorded launcher before recovering it. Unknown ownership
 retains the execution slot. `recover` is only for an existing sealed commit
-transaction; baseline/Reviewer interruptions use `/resume-task` or
-`/resume-review`. Running cancellation uses `/abort-task` and waits for a safe
+transaction; baseline interruptions before `baseline.json` exists may use the
+bounded `/resume-task` route; Reviewer interruptions use `/resume-review`.
+V4 inventory capture happens after `baseline.json` is written, so an interruption
+at that stage cannot use baseline-only resume. Inspect the retained attempt,
+request approved `/abort-task` archival, correct the cause and approve a new task.
+Do not delete or overwrite baseline/RED evidence to make recovery pass.
+Running cancellation uses `/abort-task` and waits for a safe
 agent boundary before archival through the execution slot. A hung external
 process must be diagnosed and stopped before ownership recovery can succeed.
 
@@ -183,3 +256,264 @@ retained unfinished workspace. Inbox, notifications and audit data remain in
 the Git common directory. Commit-message prefix and worktree-allowlist sidecars
 remain human-owned. See [Migration](MIGRATION.md), [Troubleshooting](TROUBLESHOOTING.md)
 and [Security](SECURITY.md) for lifecycle and trust boundaries.
+
+## V5 baseline checkpoint recovery (1.1.0)
+
+V4 remains the default contract example. A new V5 contract keeps verification
+version 2 and every V4 inventory/RED/GREEN gate, and additionally requires an
+explicitly approved `recovery` object. Adding it to V4 is rejected. For example:
+
+```json
+{
+  "version": 1,
+  "scope": "baseline",
+  "maxEnvironmentRetries": 2,
+  "maxManualRetries": 1,
+  "maxSameFailureRetries": 2,
+  "maxElapsedMs": 900000,
+  "initialDelayMs": 1000,
+  "maxDelayMs": 60000
+}
+```
+
+Retry counts must each be 0..3. The elapsed window is 1000..86400000 ms;
+initial/maximum backoff must be 1000..600000 ms with maximum at least initial.
+Backoff grows exponentially with jitter. Zero retries disables that budget.
+The window starts at initial capture and stops new stages/attempts after its
+deadline; it does not forcibly terminate a stalled Gradle or Worker process.
+
+The queue runs deterministic capture before Coder starts. Full unit-test
+success seals `baseline-full.json`; successful focused discovery seals
+`baseline-discovery.json`; collection seals `baseline-inventory.json`.
+`baseline.json` is published only after all stages succeed. Recovery reuses
+completed checkpoints without changing their bytes. `baseline-recovery.json`
+retains each attempted stage, command/process logs, input binding, evidence
+hashes, failure category and persistent next-run time. One retry spends one
+budget entry even if it completes multiple stages. RED preparation,
+implementation and Review budgets are independent; capture invokes no models.
+
+Only positive network/429 signatures on failed commands authorize automatic
+retry. Test assertion/compilation, authentication and integrity failures take
+precedence over incidental network text. Real historical failures require a
+separate correction/revised task. Unknown failures remain blocked and may use
+`/resume-task` only after fresh approval within the manual retry budget.
+A manual retry has its own budget but shares the elapsed window. There is no
+public `retry-baseline` request; it is reserved for the approved scheduler.
+
+Resume requires unchanged contract, execution/target HEAD, repository inputs,
+configuration and recorded toolchain/environment binding. Human-owned files
+excluded by the sealed worktree allowlist remain outside that input snapshot;
+the exclusion policy itself is bound. All retained attempt
+artifacts and checkpoints must still match the queue-sealed ledger. Revocation,
+pause, dependency, process ownership and workspace lease checks still apply.
+Service restarts retain counters and backoff; an ambiguous interrupted RUNNING
+attempt is not automatically replayed. A rejected recovery consumes its wake,
+so corrupted evidence cannot create an automatic retry loop. Successful
+baseline/RED evidence is never replaced. Source or target-branch changes need
+a revised contract. Baseline recovery does not refresh a stale planning head.
+
+Inspect `queue status <directory> <key>` evidence `baseline-recovery` and `status.sh` evidence
+`baselineRecovery`; queue item `baselineRecovery.nextRunAt` is the authoritative
+scheduled wake (it can be null after rejection even when retained evidence has
+an old time). Failed isolated tasks retain their workspace; independent tasks
+may continue after process exit and sealing. Fixed-directory tasks still hold
+the directory while waiting. Automatic recovery does not change commit policy.
+
+## V6 Worker safety deadlines (1.1.0)
+
+New V6 contracts retain V5 baseline recovery and inventory verification and
+add an explicitly approved execution policy, for example:
+
+```json
+{
+  "version": 1,
+  "maxRunMs": 1800000,
+  "maxStageMs": 600000,
+  "terminationGraceMs": 15000
+}
+```
+
+Place this object in `execution`. Run and stage limits are 1000..86400000 ms,
+stage must not exceed run, and TERM grace is 1000..60000 ms. They apply per
+reserved Worker invocation, including resume, Review recovery, integration,
+revalidation and abort; V5's baseline retry count/window still spans its own
+attempts. V4 remains the default example. V1..V5 never gain kill authority by
+upgrading. Normal contract approval covers this policy; no repeated approval
+is needed for an in-policy timeout.
+
+The detached supervisor is outside the Worker process group, so a blocked
+Worker event loop cannot disable the deadline. The durable record tracks
+preparation, baseline, coding, review, integration and abort stages. Stage
+changes reset only the stage limit, bounded by the original run deadline.
+Log output and silence do not affect either limit. Wall-clock deadlines include
+sleep; after wake an elapsed deadline triggers termination. A backwards clock
+or unreadable process inventory stops supervision for ownership review.
+
+Before TERM and each later KILL, process identity must match a fresh process
+table: a unique inherited run marker or previously witnessed ancestry plus
+PID, start time and process group. Detached descendants retain the marker;
+ordinary Shell descendants are also recorded because macOS may hide inherited
+environments. No signal targets a process name or a whole process group.
+Unknown members, changed identities or unprovable locks preserve the active
+slot and lease with `OWNERSHIP_BLOCKED`. Commands must preserve the ownership
+environment and must not launch persistent external services. Controlled
+Gradle commands use `--no-daemon`; supervised tools also inherit
+`-Dorg.gradle.daemon=false` so shared Gradle daemons are not reused or killed.
+
+TERM intent/result and grace start are persisted before escalation. Restarting
+the scheduler keeps its detached supervisor alive; if the supervisor crashes,
+the next scheduler scan reattaches to the same Worker. Run/stage deadlines,
+known identities and TERM grace are retained. An unregistered ambiguous launch
+is not replayed. A dead queue lock can be archived automatically only when its
+recorded owner belongs to this supervised execution or its previous supervisor.
+Lock creation writes and flushes the owner record before publishing an exclusive
+hard link in the same directory. A process killed before publication can leave a
+pending file, but no occupied transaction lock; after publication the complete
+owner remains available for recovery. Older incomplete or unknown lock records
+still require explicit diagnosis. A live or unknown lock is never stolen.
+A machine reboot still requires the
+operator to start the service; this change does not install a system daemon.
+
+Two empty ownership snapshots are required before the run can be reconciled.
+On timeout, all attempts and product changes remain. A safely sealed isolated
+candidate becomes BLOCKED, allowing independent tasks to continue; dependent
+tasks keep waiting. Fixed-directory tasks retain their directory. If a local
+commit transaction exists, the task becomes INTEGRATION_BLOCKED and retains
+its lease and transaction; `recover` verifies and integrates that same commit
+without creating another one. Timeout never implies acceptance or authorizes
+new retries. The supervisor does not roll back visible commits.
+
+`queue status`, `queue status <directory> <key>` and `status.sh` expose supervision
+state/deadlines. `worker-stop-<runId>.json` records signal intents/results and
+confirmed exit, while `worker-stop-<runId>-blocked.json` preserves ownership
+failures. Raw process environments and the ownership token are not included
+in public status or evidence. `queue stop` stops scheduling, not supervision.
+After an ownership failure, inspect the recorded identities and preserve the
+workspace. `recover-execution` refuses live/unknown descendants and retains
+the interrupted workspace; then use the existing approved recovery/archive
+workflow. Do not clear leases or edit evidence to bypass a refusal.
+
+
+## V7 verification environment recovery (1.1.0)
+
+V7 adds required `stageRecovery` alongside the V5 `recovery` and V6 `execution`
+policies. The default contract example remains V4; old tasks never acquire new
+retry authority from an installation upgrade.
+
+```json
+{
+  "version": 1,
+  "maxEnvironmentRetries": 2,
+  "maxSameFailureRetries": 1,
+  "maxElapsedMs": 900000,
+  "initialDelayMs": 1000,
+  "maxDelayMs": 60000
+}
+```
+
+Retry limits are 0..3, elapsed time is 1000..86400000 ms, delays are
+1000..600000 ms with maximum at least initial. RED, GREEN and Reviewer
+verification each share one cumulative budget across calls and correction
+cycles. The phase recovery window starts at its first verification. Successful
+verification resets the consecutive-failure counter, never the retry counter
+or elapsed window. This is not a model-cost or cross-phase task-time budget.
+
+Only identified transient network/rate-limit failures of deterministic
+verification may retry. Real assertions, compilation failures, configuration,
+unknown errors, scope/integrity failures and signal termination never grant
+retry authority. RED still requires the approved behavior failure and all
+existing regression checks. Environment retries do not consume preparation
+fixes, implementation gate attempts or Review correction cycles. Review
+verification exhaustion becomes BLOCKED without creating CHANGES_REQUESTED.
+The same model invocation remains responsible for the script result; no model
+call, approval, local commit or integration transaction is automatically replayed.
+
+Backoff is exponential with jitter and a persisted next-run time. The bounded
+wait retains the Worker slot; V6 supervision still enforces its deadline and
+covers blocked commands. Scheduler restart leaves that Worker running. Attempts,
+counts and deadlines live under `evidence/<task>/stage-recovery/`. Logs and
+inventory attempts are retained and checked before retries, along with the
+contract, HEAD, working files, configuration, tool environment and sealed
+baseline/RED evidence. New calls never reuse a previous successful verification.
+The queue seals each phase ledger's SHA-256 through the active supervised
+Worker. Rewriting or deleting a ledger cannot reset its counters or backoff;
+unowned checkpoint calls are rejected. Approved product deletions remain part
+of the input snapshot, and restoring a deleted file during backoff invalidates it.
+
+Changed inputs or evidence stop the phase. A crashed attempt with no durable
+outcome or an occupied recovery lock also stops; no timeout steals a lock.
+An exhausted phase cannot be reset by re-invoking a command. Preserve evidence
+and use the existing approved archive/revised-contract workflow. This protocol
+does not add automatic recovery of unknown outcomes, provider errors, or retries
+after a Worker termination. `queue status <directory> <key>` and `status.sh`
+expose `stageRecovery`; real Android/provider and physical sleep/reboot tests
+remain separate acceptance work.
+
+
+## V8 isolated integration and planning refresh (1.1.0)
+
+V8 retains all V7 inventory, baseline recovery, stage recovery and Worker deadline
+policies, and requires `continuity`:
+
+```json
+{
+  "version": 1,
+  "isolatedAutoIntegration": true,
+  "planningRefresh": "completedQueueTasks",
+  "planningInputs": [
+    "app/src/main/java/example/Feature.kt",
+    "app/src/main/java/example/Dependency.kt",
+    "app/src/test/java/example/FeatureTest.kt",
+    "app/src/test/resources/**"
+  ]
+}
+```
+
+Set `isolatedAutoIntegration: true` only with both `workspaceStrategy:
+"isolatedWorktree"` and `commitPolicy: "autoCommit"` in the sealed draft. The
+approval question explicitly grants automatic local integration. Existing
+contracts, including queued fixed-directory auto-commit tasks, do not gain this
+authority from a default policy change. V8 also binds the workspace strategy at
+approval; restore it or approve a revised task after a repository policy change.
+The default example remains V4 and new-install defaults remain human approval.
+
+After fresh full tests, build and independent Review, the same repository slot
+verifies and fast-forwards the approved local target. The persisted five-stage
+commit transaction binds the candidate, parent, tree and original authorization.
+No remote operation or fabricated human-acceptance record is produced. Pause
+prevents new reservations; revocation or an abort request prevents starting an
+automatic commit. Target drift, source checkout drift or unsealed changes stop
+integration. This does not authorize an automatic merge, rebase or new model
+attempt. An existing transaction keeps its lease for explicit `recover`, which
+reuses its recorded commit. Before a transaction exists, a failed isolated task
+can be safely sealed and released after process exit, so independent tasks can
+continue; its dependents still wait for actual COMPLETED integration.
+
+`planningInputs` declares the files and selectors whose contents informed the
+requirement, interfaces, design and approved test meaning. Include dependencies
+and relevant tests/resources, not just editable files. At draft time the queue
+seals a digest of matched paths, Git blob IDs, modes and selectors at the fixed
+planning HEAD. Empty matches represent absent inputs, so future additions are
+also detected. Symlink and submodule inputs are rejected. The selectors grant
+no edit permission and do not replace `allowedPaths`. An incomplete declaration
+cannot prove semantic independence; Planner must disclose uncertainty and use
+`planningRefresh: "reject"` when dependencies cannot be stated reliably.
+
+With `completedQueueTasks`, prepare may advance the execution baseline only if:
+
+- Every declared planning input is unchanged, including matched file additions,
+  deletions and executable modes.
+- Execution configuration is unchanged. Other completed tasks' sealed plan and
+  contract files are exempt; build scripts and verification configuration are not.
+- Every intervening commit forms one linear chain of completed queue integrations
+  on the same local target, with matching approval and persisted transaction.
+  Unrecorded external commits and merge commits require a revised contract.
+
+Changed inputs or denied refresh enter BASELINE_REVIEW before workspace creation
+or model execution. Use `planningRefresh: "reject"` to require reapproval on any
+HEAD advance. Legacy contracts retain their existing allowed-path drift rules.
+The original contract, planning HEAD and input digest remain unchanged; queue
+`planning-baseline` evidence records the actual execution HEAD, prior integrated
+tasks and decision. Prepare and capture a new baseline on that execution HEAD;
+never reuse another task's baseline, RED or Review evidence. Refresh is available
+only before execution, not a way to reset an existing task's retry budgets.

package/docs/SECURITY.md

@@ -1,7 +1,7 @@
 # Security model
 
 This document describes the security properties of
-`@frankzhang2026/opencode-android-orchestrator@1.0.5`. The lifecycle foundation
+`@frankzhang2026/opencode-android-orchestrator@1.2.0`. The lifecycle foundation
 completed the real OpenCode `1.14.22` and `1.15.13` release matrix in `0.2.0`;
 `1.0.0` retains that compatibility boundary.
 
@@ -43,7 +43,10 @@ selections. The configured `humanApproval` policy additionally requires final
 candidate acceptance. Configured or explicitly selected `autoCommit`
 authorization is sealed during contract approval and replaces only the final
 human question; build, actual full unit tests and independent Review remain
-mandatory.
+mandatory. Isolated automatic integration additionally requires new V8 authority
+bound to its approved workspace strategy. Planning refresh preserves the original
+approval and is limited to unchanged declared inputs across recorded completed
+queue integrations; it cannot authorize arbitrary target changes.
 
 The plugin observes the host's question arguments and completed answer
 metadata through the common before/after hooks. Its one-use receipt binds

package/docs/TROUBLESHOOTING.md

@@ -1,7 +1,7 @@
 # Troubleshooting
 
 Use this guide for
-`@frankzhang2026/opencode-android-orchestrator@1.0.5`.
+`@frankzhang2026/opencode-android-orchestrator@1.2.0`.
 
 ## Start with read-only evidence
 
@@ -11,7 +11,7 @@ From the repository root, capture:
 git status --short --branch
 git rev-parse HEAD
 opencode --version
-npx @frankzhang2026/opencode-android-orchestrator@1.0.5 doctor . --json
+npx @frankzhang2026/opencode-android-orchestrator@1.2.0 doctor . --json
 ```
 
 If installation never completed, doctor will correctly report a missing or
@@ -31,6 +31,18 @@ The CLI uses these exit codes:
 `init`, `upgrade`, and `uninstall` structures successful results; thrown errors
 remain human-readable on stderr with a stable code such as `[FILE_CONFLICT]`.
 
+## Nested Android builds (development)
+
+For an installed nested Android build, inspect
+`automation/config.json → androidProject.capabilities.buildRoot`. The wrapper,
+settings and `local.properties` belong in that selected directory. Run managed
+scripts from the Git root; for a manual Gradle command, use the selected build
+directory. In isolated worktrees the Worker resolves the source checkout's SDK
+configuration before starting; ignored `local.properties` is not copied.
+Do not replace the selected directory with a symlink or point it at a sibling
+build. A selection/configuration mismatch requires investigation and a reviewed
+installation change, not a fallback to another wrapper.
+
 ## Company npm Registry override
 
 If `npm config get registry` reports an internal Registry and a request fails
@@ -39,9 +51,9 @@ command-scoped override:
 
 ```sh
 npm --registry=https://registry.npmjs.org/ view \
-  @frankzhang2026/opencode-android-orchestrator@1.0.5 version
+  @frankzhang2026/opencode-android-orchestrator@1.2.0 version
 npx --yes --registry=https://registry.npmjs.org/ \
-  @frankzhang2026/opencode-android-orchestrator@1.0.5 upgrade . --json
+  @frankzhang2026/opencode-android-orchestrator@1.2.0 upgrade . --json
 ```
 
 This leaves the company's saved npm configuration unchanged. Use the option
@@ -71,7 +83,7 @@ Git-backed Superpowers plugin at runtime.
 | Invalid `--long-command-timeout-ms` | The value is not an integer from `120000` through `7200000`. | Use the `1800000` ms default or pass an intentional bounded value to `init`/`upgrade`; do not edit the generated config directly. |
 | Android SDK failure | No valid explicit SDK, `ANDROID_HOME`, `ANDROID_SDK_ROOT`, or `local.properties` `sdk.dir` was found. | Configure one real SDK root containing `platforms/` and `build-tools/`. Do not publish `local.properties`. |
 | Missing `git`, `jq`, `rg`, `shasum`, or Java | Required deterministic command is unavailable on `PATH`. | Install or restore the missing command, record its version, and rerun the read-only checks. |
-| `Bundled Orchestrator skill is unavailable` | The installed `1.0.5` package is incomplete, damaged, or loaded from an unsupported partial copy. | Reinstall the exact package, inspect its `resources/third-party/superpowers-v6.2.0/skills/` entries, restart OpenCode, and rerun `opencode debug skill`. Do not add an external Superpowers plugin as a fallback. |
+| `Bundled Orchestrator skill is unavailable` | The installed `1.2.0` package is incomplete, damaged, or loaded from an unsupported partial copy. | Reinstall the exact package, inspect its `resources/third-party/superpowers-v6.2.0/skills/` entries, restart OpenCode, and rerun `opencode debug skill`. Do not add an external Superpowers plugin as a fallback. |
 | `current process does not own this task queue execution` immediately after Coder start on 1.0.1 | OpenCode created the tool shell in a separate process group, so 1.0.1 rejected a legitimate Worker descendant. | Upgrade to 1.0.2 or later, restart OpenCode, then use the approved resume or abort workflow for the retained task. Do not edit the queue or lease files. |
 | The exact Superpowers v6.2.0 plugin remains after upgrade | That entry existed in the verified pre-install OpenCode file and is therefore user-owned. | Leave it in place or remove it as a separate reviewed configuration change. Upgrade only removes the old Orchestrator-managed entry. |
 
@@ -88,7 +100,7 @@ silence of `./gradlew tasks --all --console=plain | rg ...` in a large build.
 For an existing installation, run:
 
 ```sh
-npx @frankzhang2026/opencode-android-orchestrator@1.0.5 upgrade . \
+npx @frankzhang2026/opencode-android-orchestrator@1.2.0 upgrade . \
   --refresh-gradle-discovery
 ```
 
@@ -97,7 +109,7 @@ least `1800000` milliseconds. A higher timeout already supplied by the caller
 is preserved; unrelated Bash commands are unchanged. To configure one hour,
 run `upgrade . --long-command-timeout-ms 3600000` on a healthy installation.
 If a command still reports `120000 ms`, confirm that the project manifest and
-OpenCode plugin reference are both `1.0.5`, restart the OpenCode session so the
+OpenCode plugin reference are both `1.2.0`, restart the OpenCode session so the
 plugin reloads, and rerun doctor before attempting recovery.
 
 After installation, inspect OpenCode discovery separately:
@@ -251,7 +263,7 @@ session or a missing notification is not evidence that a task never started.
 | Isolated capacity reached | Integrate or explicitly archive retained workspaces; do not delete failed work simply to advance the queue. |
 | Execution launch ownership unknown | Stop the recorded launcher, prove it exited, then use `queue recover-execution .`; preserve any partial workspace. |
 | Dead transaction owner | Inspect the lock record and use explicit `queue recover-lock .`; a live PID or surviving child process blocks takeover. |
-| OpenCode process failure | Inspect the current agent log, repair provider/environment access, then clear the fault while idle. Resume alone does not clear it. |
+| OpenCode process failure | Inspect the task's agent log and repair the diagnosed cause. Use the applicable approved recovery or abort route. An agent exit alone does not set a shared fault; fixed mode still retains its workspace, while sealed isolated failures allow independent tasks to continue. |
 | Local commit already exists but task is blocked | Use `queue recover . TASK-ID`; it reuses the sealed transaction instead of creating another visible commit. |
 | Target advanced for an isolated candidate | Request `revalidate`, wait for fresh full tests/Review, and confirm the new candidate. |
 | Upgrade/uninstall reports a retained workspace | Stop scheduling and finish or approve abort before replacing runtime resources. |
@@ -280,3 +292,64 @@ For escalation, provide the command, exit code, stable error code, redacted
 details, OpenCode version, package version, current branch/HEAD, and the list of
 affected paths. Share file contents only after applying the guidance in
 [Security](SECURITY.md).
+
+## 1.1.0 V5 baseline recovery
+
+For a V5 task blocked during capture, inspect queue `baselineRecovery` and the
+retained `baseline-recovery` evidence. A non-null future `nextRunAt` means the
+scheduler is backing off inside the approved environment budget; leave the
+attempts intact. A null time with budget/deadline exhaustion stops automatic
+retry. Unknown failures need `/resume-task` approval within the manual budget.
+Assertion, compilation, authentication, historical baseline and integrity
+failures require diagnosis/correction or a revised task, not repeated resume.
+
+A changed ledger/checkpoint, execution/target HEAD, source input, configuration
+or bound toolchain prevents reuse. Restore nothing by deleting evidence.
+A RUNNING attempt left by a crash has no durable outcome and cannot be retried
+automatically; account for the entire process group before the existing
+approved abort/archive workflow. V5's elapsed limit does not kill a hung
+process. V4 baseline recovery rules remain unchanged.
+
+## Worker deadlines (V6 development protocol)
+
+A deadline stop reports the stage, run/stage deadline, TERM time and any KILL
+escalation. A silent but in-budget compile is allowed to continue. Scheduler
+stop/start does not reset budgets or stop its independent supervisor.
+If the supervisor itself exits, start the scheduler to reattach to its recorded
+Worker. Unknown ownership, PID generation changes, unreadable process tables,
+live/unknown locks and ambiguous launches remain occupied for diagnosis.
+
+Once all owned processes have exited, isolated stopped candidates can release
+the execution slot after sealing. An integration interruption preserves the
+commit transaction and lease; use `recover` to complete the existing commit.
+For `OWNERSHIP_BLOCKED`, inspect retained evidence and account for all recorded
+processes before `recover-execution`; it will refuse any live/unknown owner.
+Never use process-name-wide kills or remove a lease to make the queue advance.
+
+
+## V7 stage verification failures
+
+Inspect `stageRecovery` in task status and `stage-recovery/<phase>.json` in the
+task evidence. WAITING records the persisted backoff; EXHAUSTED means the phase
+budget/window or no-progress bound stopped retries. BLOCKED means inputs,
+evidence or another invariant could not be preserved. Do not edit these records
+or remove locks to get another attempt. Unknown or incomplete process outcomes
+require ownership diagnosis and the existing approved archive/new-contract
+route. A Reviewer environment stop preserves the sealed candidate; it does not
+request a Coder implementation correction or count as approval.
+
+
+## V8 continuity stops
+
+Inspect queue details `planning-baseline.refresh`: input drift, protected
+configuration drift, disabled refresh and unrecorded target commits each explain
+why preparation stopped. Preserve the original contract and approve a revised
+proposal; do not replace its planning digest or baseline evidence. Restore a
+changed repository workspace strategy or obtain fresh V8 approval.
+
+For isolated automatic integration, a changed target or source checkout stops
+before a new commit intent. Preserve the candidate and resolve the drift through
+a revised task. If `commit-transaction.json` already exists, retain its lease and
+use queue `recover` after diagnosis; this reuses the same local commit. It must
+not be discarded to free capacity. Other safely sealed pre-commit failures do
+not stop independent tasks, but dependents continue waiting for integration.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@frankzhang2026/opencode-android-orchestrator",
-  "version": "1.0.5",
+  "version": "1.2.0",
   "description": "Reusable OpenCode orchestration for Android projects",
   "license": "MIT",
   "author": "frankzhang2026",

package/templates/.opencode/agents/scheduled-coder.md

@@ -109,7 +109,14 @@ literally. Do not infer missing requirements and do not ask questions during a
 non-interactive run. If anything is ambiguous or blocked, stop and report the exact
 reason; the deterministic scripts own state transitions.
 
-For schema V3 tasks, keep production code unchanged while adding the approved
+For schema V4/V5/V6, successful claim must first seal the focused baseline inventory.
+Do not edit tests before claim succeeds. Existing tests join the approved
+behavior cases automatically; keep their coverage and all sealed test/resource
+inputs intact. Use status evidence to inspect missing, newly skipped or extra
+cases and the reported recovery action. An allowed existing skip does not
+authorize any new skipped behavior.
+
+For schema V3/V4/V5/V6 tasks, keep production code unchanged while adding the approved
 tests, then call `./scripts/automation/record-red.sh <TASK-ID>` with no model-
 chosen failure text. The script checks every declared case. A familiar exception
 name in a log is not sufficient RED. Fix a test-only preparation error only when
@@ -124,3 +131,9 @@ Treat `.automation-worktree-allowlist` and the status JSON's
 edit, stage, report, or use them as task evidence.
 Passing tests never grants permission to push, merge, create worktrees, alter
 automation rules, or declare the task ready for review yourself.
+
+For V6 the approved independent supervisor enforces wall-clock deadlines.
+Controlled Gradle entries disable shared-daemon reuse. Never unset Worker
+ownership variables, launch persistent detached services, or bypass controlled
+entries to extend a deadline. If ownership or termination is blocked, preserve
+the candidate and stop; no extra implementation or retry is authorized.