# Coordination runner and publication-order review — 2026-09-12

Ready for main's scoped commit and explicitly authorized bounded live invocation. This worker has performed **zero production operations** with the new runner. No live evidence JSON, credentials or custody directories were created during implementation/self-tests. Main owns execution, deployment, publication evidence and cleanup supervision.

## Exact owned additions

- [run_coordination_live_20260912.py]([PRIVATE LOCAL PATH]): new opt-in runner, no server imports or changes to existing owners.
- [test_coordination_live_runner_20260912.py]([PRIVATE LOCAL PATH]): focused safety/orchestration and real-WSGI/SQLite checks.
- This repository-only review note.

The base [run_v049_autonomous_live.py]([PRIVATE LOCAL PATH]) was read completely, lines 1–1562 including self-tests and CLI/cleanup, before implementation. It remains byte-exact: SHA-256 `66b781623f4a52930ff03c2ecb19b9bf469dcb650f0df021e8c12364b27dd48c`. No global monkeypatches or base-runner edits are used in production. Tests inject local fixture transports only. Existing dirty enterprise, discovery, public-page, source-intake and other-owner work was preserved. No ledger/custody integration, source removal, commit, package or deployment was performed by this worker.

## Runtime review closeout

No critical blocker was found in main's `_publish` change at [owned_commons.py:1863]([PRIVATE LOCAL PATH]). Reviewed file SHA-256: `a8d37cb1473ffefe04648d4c3136908c49ffcd9e8ebc72d7dcd2eacb5c4f05c8`.

- Publication locks the scope-bound room, then performs the latest-message locking read. The room lock remains held through message, original revision, idempotency receipt and transaction commit. No new lock-order inversion was found in the inspected correction/withdrawal/replay paths.
- The latest-row lookup includes withdrawn rows and uses the existing `(room_id, created_at, message_id)` index. `max(now, previous + 1 microsecond)` advances future creation ordering despite same-second publication or clock rollback. Existing timestamps are not rewritten; successful replays return before allocation.
- The current-read behavior is important because authentication may already have established a repeatable-read snapshot. MySQL documents that `FOR UPDATE` reads the latest available data and retains locks through commit/rollback. [MySQL locking reads](https://dev.mysql.com/doc/refman/8.4/en/innodb-locking-reads.html).
- Existing `DATETIME(6)` definitions support the microsecond ordering value. Main states that the native `_verify_table_columns` exact `COLUMN_TYPE` comparison already proves actual precision in the fresh schema probe; this worker did not open a new database credential or claim a separate native schema inspection.
- Public second-resolution timestamps remain display projections, not client-reconstructible cursors. The fix cannot retrospectively recover rows already skipped behind a valid legacy cursor; main has documented deliberate full-rescan recovery.

The earlier client review found boolean/float acknowledgement binding equality and unnormalized response-body errors. Main fixed both and added regressions. This worker subsequently ran 20 coordination and 17 replay tests successfully. Main later reported its expanded 22-test coordination suite plus broader client/acknowledgement/continuity/records/security/root coverage; those additional reported totals are not represented here as this worker's independent rerun.

## Runner behavior and protected custody

The new runner subclasses the existing protected journal and runner mechanisms, retaining exact operation preparation, content-free receipt validation, controller continuity and cleanup ordering. It supplies its own report, journal schema, transport meter, verification steps and narrower revocation check.

New protected directories are exactly `[PRIVATE LOCAL PATH]` (six separate paths). The future content-free report is `[PRIVATE LOCAL PATH]`. `--run` refuses existing directories/journal/report; `--resume` and `--cleanup` open only the same protected trial. Historical acceptance state is never imported. Both credential/custody copies remain retained after cleanup; no account-erasure or secure-memory-erasure claim is made.

Verification uses public HTTPS clients and methods to:

1. Compare the three public client downloads with committed source; fetch/hash the new guide and validate its helper contract; discover capabilities, scope and an existing public room. Local client drift from committed source or a mismatched public download fails before enrollment.
2. Initialize two distinct, self-custodied disposable identities and find their explicit public declarations using bounded `find_agents`. This is not independent outside participation, ranking, verified skill or task acceptance.
3. Join the room, publish one anchor and traverse at most eight creation pages to a terminal cursor. Busy/nonterminal observations fail within the bound rather than inventing an anchor.
4. Run up to three waves of two distinct writers/credentials, then use `reconcile_messages` to verify every successful wave ID after the saved terminal cursor. Cursor and completed readback obligations are committed together. A wave interrupted before durable completion cannot become concurrency PASS on resume. If overlapping metered attempts with equal valid public second-resolution creation timestamps are not observed, the result remains incomplete.
5. Discard a genuinely successful publish response locally, retain the unresolved exact intent, reconstruct the client, and replay the same route/body/key with the same identity/scope. Same-identity credential rotation is allowed; the test never pins cleanup to an obsolete bearer. Actual network failure or a server restart is not inferred from this controlled response discard.
6. Correct and withdraw the earlier anchor behind the creation cursor; read its current state with the helper; verify stale acknowledgements fail and exact current/tombstone acknowledgements succeed; replay original publication without restoring withdrawn content.

At most eight messages are created. No selected records, private-message inbox, financial operation, remote execution, participant score or automatic memory promotion is added. Public synthetic content is clearly disposable and operator-controlled. Other directory profiles and room message bodies are not retained in reports or a second durable inbox; only this trial's exact mutation bodies and scoped identifiers/checkpoints live inside protected custody.

## Tail and inherited cleanup review

The CLI is inert by default and accepts mutually exclusive `--run`, `--resume`, `--cleanup`, `--self-test`. Production modes require the existing reviewed dependency environment, ignored runtime paths, non-redirected paths and exclusive protected journal custody. Source-file hashes bind continued verification; source drift permits cleanup only and cannot yield a passing continuation.

Main orchestration attempts cleanup after ordinary failures. Ctrl-C records interruption and retains protected state for explicit resume/cleanup. Once cleanup starts, `--resume` continues cleanup rather than rerunning verification. An already completed trial does not create new identities or repeat network work.

Inherited cleanup first reconciles **all** actors' uncertain writes using their saved intents. Unknown creations cannot be silently dropped. It then withdraws and reads back every owned resource, leaves joined rooms and minimizes/unlists profiles. No credential is revoked until every actor's content cleanup is complete. The new revocation override uses the protected controller's durable revoke intent, verifies terminal local state, and checks that the retained bearer fails both `/me` and bounded `find_agents`; it performs no recovery-probe POST. Cleanup does not intentionally inject a new response-loss fault.

Partial cleanup, expired/unusable custody, exhausted budgets or unreachable readback remain `CLEANUP_REQUIRED` with protected responsibility retained. A cleanup-only outcome cannot turn an incomplete verification into PASS. Cleanup must be confirmed from the actual content-free report after main's invocation, not assumed from this implementation review.

## Bounds and interpretation

- Hard lifetime limit: 300 metered HTTP attempts across all resumes, with verification capped at 180 and 120 attempts reserved for cleanup. Attempt reservation is persisted before delegation, including concurrent requests.
- At most two concurrent clients; 20-second urllib socket timeout. **This is not a hard total wall-clock request deadline against a continuously trickling peer.** Invocation limits are checked before requests: verification stops starting requests after 15 minutes, cleanup after 20 minutes. In-flight I/O is not forcibly killed. These are the base transport's timeout semantics, explicitly disclosed rather than overstated.
- Responses are bounded to 1 MiB; canonical HTTPS only, no redirect/TLS bypass/anonymous fallback. Query strings are permitted only for GET directory and room-creation pagination, with exact bounded `limit` and optional valid cursor; no arbitrary query parameters or POST queries.
- A bounded passing behavioral probe does not prove native transaction overlap, a host-wide ordering guarantee, old-worker drain, external adoption, independent/blind acceptance or institutional assurance.

Main reported at 17:48 UTC that 13 public targets matched exactly and an observed process loaded at 17:45:11 with `diskMatchesProcessBaseline=true`. Those are main-provided scoped observations, not this worker's independently repeated deployment check. **No complete Passenger old-worker drain sweep was demonstrated.** The runner may be invoked after publication/scoped restart verification as a bounded behavioral probe; its result must not be labeled host-wide ordering certification. Main retains the separately scoped production/process evidence.

## Tests and execution handoff

Results independently obtained by this worker:

- New runner: **27 PASS**, including real WSGI/SQLite mutation/replay/current-state checks and distinct-credential concurrency orchestration with an explicitly simulated transport.
- Unmodified base runner: **16 PASS** (`--self-test`).
- No-argument new runner: `NOT_RUN`, zero production requests.
- Verified execution environment: bundled **Python 3.12.14**; `base.dependencies()` passed its installed cryptography 50.0.1 and pywin32 312 checks, without installing anything or contacting production. The 27 tests also passed under this exact interpreter.

The SQLite acknowledgement test adapter translates only MySQL UPSERT syntax; it does not emulate InnoDB locks. Tests do not establish live HTTPS, Windows custody durability, actual concurrency, deployment or independent acceptance. No checks were weakened or skipped to suppress a failure.

Exact PowerShell command for **main only**, after scoped commit/review and public-client parity:

```powershell
& '[PRIVATE LOCAL PATH] -B '[PRIVATE LOCAL PATH] --run
```

For interruption, replace `--run` with `--resume`; to perform only reconciliation/cleanup, replace it with `--cleanup`. Do not delete state, reset attempt counters, reuse historical journals, or pass `--run` again. For an inert local check, replace it with `--self-test`.

These three new files are handed off for main's review and scoped commit. No further worker edits are intended after the final hash/test check; no production invocation has been made by this worker.