FLOW-09 — operating status and gated plan¶
Status checked 2026-09-23, 18:32 Europe/Warsaw. Plan task:
80708faa-d90a-4d07-af70-8d86f62a8bc9; initial status-audit task:
62d9129b-84f8-4cea-a76c-5ca7d7bcc4e9.
What works now¶
FLOW-08 and all six of its selected children read back as done with receipts.
Production server a2b0a6c and installed Bridge bc13310 completed an actual
catalog-backed background test on the ordinary enrolled Mac: automatic pickup,
four fresh native sessions, a rejected candidate, correction, independent
acceptance, two Git commits and one server acceptance receipt in 151.45 seconds.
The complete server test suite had 294 passes; Bridge had 102 Rust passes and
green macOS CI. Foreground project list and snapshot took 0.142 and 0.572
seconds after the test. Details and qualifications are in the
FLOW-08 production report.
The installed Bridge LaunchAgent is running; doctor reports authenticated
Codex and Claude profiles. Background authorization is disabled and the
synthetic policy's four-attempt budget is exhausted. There is no authorized
ordinary project task waiting for this node under that policy. The present
release requires an awake Mac. No claim is made that a new natural-language
request automatically becomes an executable task: a person or client still
needs to define the goal, acceptance criteria, Git base, agent versions and
local policy, then call catalog dispatch.
The live state authority is the HeyAira task/workflow and its receipt. Work
Center shows an on-demand server snapshot and must be refreshed. A provider
exit or a local Git commit alone does not close the task. A done workflow
requires the server's accepted verifier verdict and receipt; Git publication
is a separate release step.
Why the older backlog looks unfinished¶
Before FLOW-09 was created, the project had 22 open records: 8
in_progress, 5 blocked, 9 todo. These are not 22 currently running
agents. Some are old experiment fixtures, some belong to separate owners or
future product work, and some have stale handoffs. The table is an inventory
of HeyAira records, not a claim that their historical completion text was
independently re-tested today. FLOW-09 adds two new records: one parent and
one active child.
| Existing status | Records | Next disposition |
|---|---|---|
In progress: Bridge Work Center c58d504b; Bridge SessionPlan 4520ee92 |
2 | Relevant neighboring work. Reconcile each full receipt and installed revision before changing its status. The Work Center handoff still claims the server feed is unavailable, which conflicts with the verified installed FLOW-08 view. |
In progress: backup 10e905fd; Bridge UI f4305bb1; notifications b2b28abc; positioning 3778d1b7 |
4 | Separate scopes. Their owners or explicit successor tasks need to decide their own remaining acceptance gates; FLOW-09 does not silently close them. |
In progress: atomicity fixture 4f7e3f42; cross-client fixture 01ab35c4 |
2 | Old test records with no recent completion evidence. Review fixture results and either finish truthfully or mark blocked with a specific reason. Do not treat them as active product delivery. |
Blocked: rotation duplicate ed0772d6 |
1 | Explicitly superseded; retain its blocked/superseded reason until a supported cancellation or archival disposition exists. |
Blocked: summary fixture a80ace99; BIND-3 b3da6359; access/log probes a4716af6, b1140376 |
4 | Recheck their original conditions in their own scopes before updating; older BIND-3 access errors may no longer describe current connections. |
Todo: wake 83ad0765; push 336d5a95; sleep readiness 255655c3; listing 1a598a87 |
4 | Future/owner work. Hardware wake was explicitly deferred. Do not interpret todo as authorized execution. |
Todo: connectivity/retry fixtures adb32efa, a28e1083, 7025b75c, a2ebf0f8, 935409ee |
5 | Historical tests requiring separate evidence or deliberate archival; not the current flow. |
No historical task was closed merely to make the count smaller. In particular,
the backup task still describes an unverified separate weekly restore executor;
the product notification task still includes APNs; the original UI tasks have
their own review conditions. Their in_progress labels are not evidence of
active Bridge processes. FLOW-09 tracks the new operating loop independently.
Execution order and checkpoints¶
The estimates below are work time after the prior gate, not promised calendar deadlines. Only the current stage is created as an active child; successors are created when their entry condition holds.
| Stage | Estimate | Owner / entry | Observable exit gate |
|---|---|---|---|
| A. Status truth | Half working day | Codex; started under 62d9129b |
This inventory and corrected current-state documentation exist at a Git commit; HeyAira RESULT and receipt cite that commit. |
| B. State and assignment contract | Half to one working day after A | Codex; task d96c760e-ea05-4503-8216-757feab4fc1d, prioritized by the owner |
Every stage has a persisted event, a clear broad status and a named responsible role. Current and historical attempts expose agent versions, Bridge and native session IDs; UI identifies the active role. An isolated real MCP/PostgreSQL correction cycle verifies the mapping. |
| C. First ordinary task | One working day after B | Codex coordinates; a selected worker and distinct verifier execute. Choose a bounded repository task, clean Git base, criteria, versions and finite local policy. | Actual task progresses through queued, claimed, preparing, running, verification and done, or stops visibly blocked; read back one accepted receipt, session IDs, tests and result commit. |
| D. Recovery and responsiveness | One working day after C | Codex; use controlled fixtures and the installed package | Restart, expired lease, token/Keychain denial and sleep interruption each yield a visible state and operator action; no ambiguous replay. Record bounded latency/CPU measurements. |
| E. Routine handoff | Half working day after D | Codex; start from another fresh session | A fresh session finds the active goal, owner, Git base/result, current phase, evidence and next checkpoint from HeyAira and Git alone. Release status stays distinct from task acceptance. |
For every active stage, the HeyAira handoff must state: owner, verified fact, current phase, next action, next checkpoint and exact blocker if any. Close a stage only after an evidence-backed RESULT, a task receipt, and readback. The parent plan advances to the next stage only after that gate. Hardware wake, mobile notifications, stable signing and unrelated historical backlog are separate decisions, not hidden completion conditions for FLOW-09.