Work task continuity and current-runtime recovery

Report body

Work task continuity and current-runtime recovery

Date: 2026-09-13 UTC (local work began September 12). State: implementation and verification in progress; not a production work-exchange deployment or rollback. The preceding user-answer turn clarified status only, not goal progress.

Outcome and scope

The full report-intake, useful autonomous service, typed memory, publication and testing objective remains active. This extension implements safe subsequent tasks and a recovery mode in the existing runtime. It does not replace the service with a second writable authority or close missing functionality by labeling it absent.

Evidence leads are the complete protocol and operations reviews under reports/v049-work-exchange-*-review-20260912.md, especially the resource-cost and reliability sources. Raw reports remain evidence, not instructions. No new external factual claim, market-demand assertion or standards-compliance claim is published by this change. No participant ranking, query profile or payment state is introduced. NO JUDGMENT WHATSOEVER; judgment state NONE.

Implemented behavior

scripts/concresca_work_controller.py and existing AutonomousAgent wrappers now offer advance_work_task(expected_generation, next_task_id, **configuration). Only a logically terminal task with active same-identity authority, no pending credential operation and no controller halt can advance. A protected two-copy save retains fixed-size historical spent/unknown totals and a keyed chain while selecting the next finite budget. This is a new selected task, not a refund or reset of the old task and not a claimed identity-lifetime budget.

Generation zero preserves previous binding bytes and omitted generation calls. After advancement, prepare/read/resume/resolve require the exact generation; remote keys are generation-bound and caller raw-key overrides are rejected. Duplicate advancement returns the current successor status without resetting progress. Labels can repeat without colliding with old operations. Counters and storage are bounded; overflow rejects advancement. Retry timing and historical credential barriers persist. Retired bodies, cursors, keys and object references are not archived; compact unknown costs cannot later be reconciled per attempt. Retirement neither withdraws server records nor completes a bilateral agreement.

concresca_runtime/owned_work_recovery.py supplies a frozen WorkRecoveryPolicy. The existing OwnedCommonsApplication captures CONCRESCA_WORK_MODE once at construction. Default is active; only exact active/drain values are supported. The protected-environment owner allowlists and validates this setting without weakening overrides, secret custody or existing deployment controls.

Drain denies new ordinary create/correct/propose/counter/accept/deliver/decide effects, but preserves current reads, exact successful replays, exact resolution, owner withdrawals and currently valid bound refuse/cancel. Cleanup still passes existing actor/scope/current-row/revision/digest/state checks. Work purge remains request-triggered and scope-bound, committing at most 25 due payload clearances per batch before operation locks; no new background purge service is claimed.

A 503 work_drain_active response creates neither receipt nor prevention fence. It does not prove nonexecution of a previous attempt; an unfenced request can execute after reactivation. Exact-intent resolution remains the definitive applied-or-prevented workflow. Server cleanup admission does not change client budget classification: refuse/cancel remain ordinary client costs.

Public work guide/contract and downloadable controller/agent are regenerated from their existing owners. Facade capability normalization accepts only exact mode- consistent recovery fields and exact JSON boolean types. It retains the complete route bundle and does not infer authority from unknown extensions.

Why recovery changed

No production rollback occurred in this checkpoint. The release audit found that restoring literal old schema2 application bytes onto an upgraded schema3 database would fail. The earlier derived schema3-compatible core fallback also lacks work payload purge; its native core-readback evidence is not retention- complete work recovery. Current-runtime drain avoids that missing behavior on the same database, without downgrading schema or restoring revoked authority.

Prelaunch maintenance is acceptable. Full independent acceptance is not a blanket reason to withhold an honestly bounded WIP deployment. Initial upgrade safety needs either verified quiescence or actual compatibility of already-admitted old core requests and staged imports with the additive candidate. Complete worker cessation is not assumed mandatory for that initial path. Future same-schema service-wide drain still needs an effective admission/transition barrier; one observed new worker is not proof that every old active worker stopped. Replacing a Passenger restart marker alone proves neither safety condition.

Verification so far

• Final exact repository ZIP90607128decb07a4a9a1e6ba3d6ffd5f0c290792: extracted regression805tests PASS in251.252seconds, zero failures/errors/skips, terminal process exit0. Earlier session58964 lost its final observation and its handle was subsequently missing; the complete saved-log rerun supplies this evidence, not an inferred earlier result. Detached validation and log are in the work-task-recovery-20260913 artifact directory. Both ZIPs passed fresh SHA/CRC/member checks; eight public helper downloads match source, all14 native source hashes match repository members, all16 source-family originals remain repository-only and the protected hero hash is unchanged.
• Initial pure deployment planner: scripts/concresca_work_deployment_plan.py and scripts/test_work_deployment_plan.py,27offline tests PASS in38.520seconds on main rerun. Exact outer configuration bytes are preserved, nonce/line/control checks and restore compare-and-swap fail closed, independently pinned c2 file inventory determines the allowed delta, SQL precedes candidate availability, public counterparts precede the last validator. No I/O, Apache enforcement, native old-worker compatibility or production application follows from this pure planner. Actual publisher integration and live verification remain open. Read-only integration with the real outer configuration also passed:3219bytes, SHA256 b1a69c6b6da3e7e1396e3fcb854bd0d5818fd436c4b7ecefd66654f373b7ba17, 41explicit targets and only key_epoch.py/runtime/release.json excluded from the candidate delta. Proposed maintenance was not uploaded; host enforcement remains unverified. No private configuration values were output.
• Warm initial-upgrade harness offline checks now include29tests PASS0.494seconds on main rerun. Exact source archive pin, two separately acknowledged lanes, insertion-custody-before-ACK, exact profile/receipt readback, actual-lock-state predicates and failure cleanup are modeled; native evidence remains separate.
• First native warm-upgrade invocation terminated with exit1. Exact evidence is reports/v049-work-warm-upgrade-native-failed-20260913.json, SHA256 66607e3e72f0ba9b2285a91ee897455f3c7563d39c5467d879c9c0b584f1c11d. Baseline1 passed all13 gates, actual restart and all3cold recovery phases; baseline2 stopped with warm_phase_timeout after historical_baseline. Cleanup removed158/16 owned fixture rows, isolated server exit0 confirmed and generated plaintext credentials removed. Existing services and production were untouched. This is incomplete warm compatibility evidence, not a production failure or evidence that compatibility failed. Diagnose the actual test phase and retain this result; do not relax the acceptance predicates or overwrite failed evidence.
• Fresh bounded unauthenticated HTTPS observation began2026-09-13T03:10:23.870816Z: capabilities/readiness both HTTP200; no advertised workExchange and productionReady=false. No production write or rollback was performed.
• Combined focused retirement/recovery/root/public-guide suite: 102 tests PASS, 32.922 seconds, no failures/errors/skips. It includes 34 retirement checks and three native Windows custody cases, 32 recovery checks using real owned WSGI with SQLite transport, 24 root checks and 12 public-contract checks.
• Protected-environment mode tests: 4 PASS, including exact active/drain, absent default, invalid/redacted rejection and denied ambient override.
• Existing protected-environment suite: 31 tests, no failures/errors, seven platform-related skips (including skipped subtests); not a claim of complete POSIX/symlink verification on this Windows host.
• Broader combined suite: 648 tests PASS in 222.175 seconds, zero failures/errors/skips. This includes the 576-test prior work/read/transport regression selection plus 72 new task/recovery/configuration checks.
• Expanded combined suite including native harness/runner/recovery/rollback safeguards: 793 tests PASS in281.694seconds, zero failures/errors/skips.
• Native database cold-process recovery now PASS on both v1/v2 baseline paths; see reports/v049-work-recovery-native-20260913.json. Actual MySQL 9.7.0-commercial, REPEATABLE READ, 13 original gates each, actual server process restart on the same data/port/version for each path, and three separate current- source active-before/drain/active-after probes per target. Each drain cleared exactly 25 then 2 due work payloads; not-due/foreign payloads, identity, revocation, migration/receipt/fence rows and current withdrawn readback stayed preserved. Only existing canonical room updated_at refresh is permitted by the all-table comparison. Parent-tracked cleanup removed 158/159 fixture rows; server stopped with exit0 and generated plaintext credentials were removed. Production was not accessed and existing services were not modified.
• Main review caught a pre-launch harness defect: its capsule validator confused raw wire applied with controller completed. The old validator failed a new full actual-handler capsule regression. The repaired validator preserves raw responses and rejects remapped ones. Focused native-probe model suite30PASS; companion harnessself17, resolution14 and core-recovery32 rerun PASS. This test-harness defect was not a service deployment failure.

Cold-child acceptance is deliberately scoped: startup mode, current identity/ revocation, reads, retained resolution/original replays, prevention410 and exact purge. Fresh ordinary writes and fresh authorized owner cleanup are covered by the existing parent native workflow and WSGI model checks, not falsely attributed to child reactivation. These results are not warm old-binary upgrade, Passenger, production, backup-erasure or independent participant evidence.

Initial install-order work: scripts/test_work_upgrade_import_order.py,12tests PASS in83.551seconds on main rerun, verifies the independently pinned complete c2 root archive before any member use and tests 19 fresh-import boundaries plus18 late-import crossings. Install new manifest first, dependency leaves/consumers next, route declarations/application after, and validator last under an effective outer maintenance barrier. Publishing the validator early is a retained counterexample: it admits a v3 declaration over a v2 backend. Imported old code remains old; future manifest admission closes, but an already-checked old root can load a later backend. These are offline import/availability observations, not database, Apache or Passenger proof.

Browser helpers previously failed to initialize with kernel-assets errors; this is a tester limitation, not rendering evidence or a service failure. This turn's web retrieval also failed before returning runtime content, so it adds no fresh live availability evidence.

Intake, custody and remaining work

Startup sync: integrity PASS, 16 active/fully reviewed files, 718,981 bytes, 67 closed of 83 records, no new records. Registration/full review is not implementation completion. Sources remain at their exact repository custody paths and in active intake while source-specific work remains. Typed architecture, constraints, decisions, memory, test plan, progress and continuation owners now carry this implementation and its limitations rather than merely storing it in a dated report.

Remaining work includes warm old-core/import-order compatibility, tested initial cutover, publication/live readback/public-doc pilot, credential-lifecycle metering and transport, rights/correction-dependency workflow, useful source-specific adoption work and the separate existing ChatGPT integration acceptance. No expired core receipt is renewed from these tests; no outside participation is inferred.

C: free space fell to about 250 MB during verification. Attempted removal of the known previous disposable extraction was blocked by execution policy; nothing was deleted and no alternate deletion mechanism was used. Release ZIPs, source reports, credentials, databases and unrelated user changes remain untouched. Later read-only measurement found about 5.5 GB free on C: without deletion by this task, clearing the immediate native-run space constraint. The cause of that external space change was not investigated or inferred.

The deployment audit found that current FTPS restart only verifies the marker, and historical HTTP evidence proves one changed app instance, not cessation of all prior workers. The historical publisher's target set omits new work files and its automatic restore is unsuitable after schema3 migration. Existing host-scoped stop/admission-barrier capability is being investigated before implementation; no hypothetical host API or successful cutover is claimed. The follow-up audit established that v1/v2 definitions and key old core dependencies are unchanged. Old-root manifest checks reject schema3, but already-admitted warm core requests and lazy imports need targeted compatibility evidence. This permits a smaller initial prelaunch deployment path if proved, without manufacturing a universal all-workers-stopped gate. Actual read-only FTPS observed outer .htaccess3219bytes, SHA256 b1a69c6b6da3e7e1396e3fcb854bd0d5818fd436c4b7ecefd66654f373b7ba17: PassengerAppRoot/Python and rewrite rules present, examined request-duration directives absent. Values were not exposed; no writes were performed.

Checkpoint0d576a5d034f26b370cd3bcdf22c1c41ed4d57b2 is pushed. Both committed- source WIP ZIPs built and extracted repository648tests PASS again in240.877s. Archive CRC/unique/traversal checks, all8public helper source byte matches, 16repository-only exact source reports and protected hero hash PASS. Detached validation-0d576a5-wip.json beside the ZIPs records exact sizes/hashes and the then-unverified native state; the later native result above supersedes only that native omission. The12 non-harness source hashes in the native result match that repository ZIP exactly. Native JSON is an exact-byte copy of the generated fixture summary (SHA256 e5e2084372c84d026e9f69319cf11feb960825be4ce428a41a866a7d66e89963). New native-harness/evidence packaging remains a separate checkpoint; releases stay WIP while required whole-goal gates remain open.