# App-Robot Delivery Tracking Prompt

Replace `<TASK_URL>` with the delivery URL, then paste the full prompt into Claude Code.

```text
Track app-robot delivery task <TASK_URL> to completion and actively repair anything
that prevents forward progress.

Operating rules:

1. Start with a read-only timeline audit: current task/step/run, step age, last changed
   evidence, worker/execution ownership, retry count, external operations, blockers,
   and production build SHA.

2. Treat 15 minutes without changed durable evidence as a stall. Do not accept log
   activity, repeated probes, heartbeats, or newly minted attempts as progress.

3. Never repeat the same failed action more than once. On the second identical failure,
   stop retrying, identify the shared root cause, add a focused regression test, open a
   fix PR, pass exact-head CI, merge/deploy it, verify production, then resume the task.

4. Use app-robot's supported operations only. Preserve at-most-once semantics for store
   submissions and other external mutations. Never bypass an operator-disabled store lane.

5. Check that every supervising turn has a claimable execution, bounded retry and launch
   budgets, expiring reservations, and a periodic reconciler. Repair the platform if not.

6. Parallelize independent diagnosis and fixes, but serialize overlapping PRs. Batch
   related fixes where safe. Merge overlapping PRs once in dependency order instead of
   rebasing each after every squash.

7. Run focused impacted tests during development. If local test admission waits over two
   minutes, diagnose the admission and database lifecycle and use CI as the merge gate.
   Do not wait indefinitely or start duplicate suites.

8. Perform one bounded adversarial review of each original root-cause area, using at most
   three reviewers. Aggregate confirmed findings into at most one follow-up PR per
   subsystem. Do not review review-generated follow-ups unless they introduce a genuinely
   new subsystem. Launch no recursive review fan-out.

9. Cap each review workflow at 20 minutes. At the deadline, aggregate completed evidence
   and stop incomplete or redundant workers. Cap each implementation agent at 20 minutes
   to produce a pushed commit or test result; otherwise stop it and narrow or reassign the
   task. A stalled agent is not progress.

10. Do not wait for manual cleanup that is not on the delivery critical path. Convert the
    cause into a bounded code fix and regression test, then let exact-head CI verify it.

11. Every 10 minutes report: current step, age, last real progress, active blocker, exact
    remediation, queue/CI/deploy status, remaining critical path, and any wall-clock budget
    deviation.

12. Persist a restart-safe checkpoint before context or account exhaustion: task/run IDs,
    operation IDs, PR queue, production build, monitors, and exact next commands.

13. Target four hours for a new delivery task and two hours for a repair-only critical
    path, excluding unavoidable external store review. Use these sub-budgets:
    - initial audit: 10 minutes
    - root-cause diagnosis: 20 minutes per independent failure
    - implementation agent: 20 minutes to a pushed artifact
    - review workflow: 20 minutes, maximum three reviewers
    - unchanged CI or deploy: investigate after 15 minutes
    Report a budget miss immediately; do not silently extend it.

14. Completion means: all enabled lanes have accepted outcomes; policy-disabled lanes are
    recorded as notified person waits; all confirmed root-cause fixes are merged, deployed,
    and production-verified; the repair queue is empty; bounded reviews are finished.
    Then mark /goal complete.

First response: give me the evidence-based critical path and the maximum wall-clock budget
for each remaining step. Then begin; do not merely propose a plan.
```

The limits prevent an open-ended review-of-review loop. External store review can outlast
the target, but the task must reach a durable submitted or policy-blocked state before the
tracking goal is considered complete.