Supervision and recovery
Supervise a fleet by following outcomes and evidence. Begin with the workstream: which issues are eligible, assigned, blocked or finished, and which application changes have reached users? Then inspect the run responsible for a particular issue. The managed environment supplies execution capacity and infrastructure; your intervention should resolve scope, access or acceptance decisions.
Ask for a useful status
A useful report names the workstream and issue, current assignment, last verified result, blocker and next action. It distinguishes active work from queued work and identifies stale or unavailable observations. A quiet terminal is not proof that a task is stuck, and a live process is not proof of progress.
Use the signed-in agent view and conversation/tool history available to your account. Fleet-wide scheduling and lifecycle inspection depend on the managed environment provisioned during onboarding. The CLI assistance guide covers the authorized managed CLI path; access to one assigned slot does not grant fleet administration.
Intervene at the failing boundary
| Observation | Next action | Evidence of recovery |
|---|---|---|
| Issue never starts | Check dependencies, workstream approval/pause and assigned capacity | A current assignment and observed startup |
| Startup accepted but no session ready | Report the command id and assigned slot through managed support | Session readiness |
| Agent needs a decision | Answer the specific question and update issue scope | Agent continues with the recorded decision |
| Two agents change the same files | Stop or redirect one assignment and choose an integration owner | One coherent diff with combined checks |
| A test repeatedly fails | Inspect the actual failure and changed behavior before rerunning | Relevant test passes on the corrected revision |
| Session ends during implementation | Recover the existing workspace and last recorded result | Saved changes inspected and a clear continuation |
| Merge succeeds but app serves old behavior | Follow managed publication and deployed revision | Intended revision plus a matching smoke response |
| External connection fails | Check that integration's account permissions and service response | A successful authorized operation |
Example: the change merged, but the old behavior remains
Suppose a duplicate-handling fix passed its tests, yet the support app still creates two queue entries. Keep the issue open while you establish which revision is serving. If publication or rollout has not completed, Redgold recovers that stage. If the intended revision is live, capture a sanitized reproduction and inspect application behavior and data assumptions.
Repeating implementation before checking the revision can create another fix for code that has not run yet. Repeating a write before checking its result can also create more duplicates. Use the smallest authorized read to establish state.
Review the intervention too
Record the decision or recovery action on the issue, including the affected revision and new verification result. A cancelled task needs a reason and a review of dependent work. An active run needs explicit interruption if it should stop; pausing its workstream only prevents new dispatches.
See the application workstream example for how these decisions fit into a complete managed delivery.