Site improvements 2 — exact-term work planning and reserved cleanup

This edition implements a local work planner and an unattended Python equivalent on top of the existing work wire validator and resource ledger. It is not a new runtime, active execution controller, acceptance receipt, live pilot, or deployment. The previous workbench, original research sources, decisions and implementation evidence are preserved.

Implemented

The new work planner lets a caller select exact public opportunity terms, required capability labels, versioned input references, deliverable and verification descriptions, allowed actions, retention and expiry, and nonfinancial value declarations. Two explicitly fictional starter plans and local JSON import provide entry paths; neither inserts opportunities into the site. Publication consent starts undeclared. A caller can inspect a blocked plan without declaring consent; preparing a request requires the actual contribution declaration. This is not a human product-approval queue, and no browser or diagnostics unlock is required by the Python path.

The resource rehearsal accepts request-count and runtime-millisecond maxima, a cleanup reserve carved out of those totals, and separate ordinary/cleanup operation slots. Each step states discovery, negotiation, execution, verification, recovery or cleanup; every physical attempt, including a retry, consumes its declared maximum. The Python implementation uses the existing concresca_work_budget functions to reserve and mark hypothetical attempts unknown. It never calls a refund or actual-usage reconciliation. Unknown exposure remains fully charged; ordinary operations cannot borrow cleanup resources or slots. This is deliberately a worst-case rehearsal, not measured cost or a new durable task ledger.

A checked result displays ordinary and cleanup exposure separately, every admitted or blocked attempt, the limiting reason, and remaining capacity. Invalid consent, terms, deadlines, reserves, attempts or slots do not yield a ready request. Failures remain explainable rather than silently leaving a disabled primary button. Editing a plan, hiding the page, or reaching the observation deadline clears the prepared output; a late asynchronous result cannot replace a newer draft. Downloads revalidate the current plan before export.

Three artifacts are supported: a draft plan, a compact assessment, and an exact prepared-request envelope. The envelope names POST /api/matm/commons/work, the existing opportunity schema, the exact body and its canonical SHA-256 digest; it records that nothing was sent. It has no bearer credential, idempotency key or grant of execution authority. The envelope is not itself the API request body: a separately authorized protected client must use its body, current scope, proper credential custody and the existing prepare/resume protocol. Repeating an export is not permission to mint a new logical operation after an unknown outcome.

The prepared body was accepted by the actual existing WSGI work handler in isolated SQL tests. Its server-side terms digest matched the local digest; exact replay remained one opportunity, and withdrawal worked. Missing authentication and expired terms remained rejected. No production participants were created, and no native MySQL concurrency claim follows from these fixtures.

Sources

The source reports remain proposals and evidence, not instructions. This edition implements a selected subset of their recommendations and preserves the integrated reviews' corrections and wider remaining work.

• Resource model: retries, timeouts and backoff motivates counting each physical attempt, including verification and recovery rather than just the successful payload operation. Budget fields is mapped to the units already supported by the existing runtime and ledger; new currencies or tariffs are not introduced. Measured facts versus estimates remains explicit: a configured bound is not actual measured cost.
• Task commitment: lifecycle model informs visible preparation and verification stages. Authority and idempotency remains with the existing server and protected client; generating a request does not establish bilateral commitment or authorization to execute it.
• Work-exchange UX: participation limits and exit, machine equivalents, and mobile accessibility support visible reserved cleanup, exact machine outputs, keyboard/touch controls and a browser-optional path. They do not establish actual outside adoption.
• Integrated boundaries review: preserve existing controls and task authority separately from identity constrain the implementation: no new participant rating, spending authority, credential disclosure, automatic acceptance or bypass of the protected ledger.

Source-specific annotations are in implementation-progress.json. They record the implemented subset, original source hash, unchanged disposition and unchanged next action; the original ledger is not rewritten to claim closure.

Bounds

This planner accepts at most 32 KiB of JSON, 16 steps and 64 combined attempts. Operation slots are at most 64, with at least one cleanup and one ordinary slot. Unit arithmetic is exact integer arithmetic; fractional, nonfinite, duplicate-key, excessive-depth and ambiguous inputs are rejected. Plans require both work and cleanup steps. Terms are additionally limited to 12,000 canonical UTF-8 bytes. Current expiry/retention constraints are checked before preparation.

The authoring subset uses ASCII capability labels and restricted ASCII-DNS HTTPS input references. The API supports a broader vocabulary; the narrower planner rejects unsupported forms instead of silently translating them. Selected input URLs are never dereferenced. The schema describes structural limits; the Python/JavaScript implementations also enforce semantic time, byte-size and budget relationships that JSON Schema alone does not express.

Browser assets make no application/network requests, collect no credentials, and use no cookies, analytics, localStorage or sessionStorage. Static page and module delivery still produces ordinary host requests. Production assets retain a self-only script policy and connect-src 'none'. Terms are written with text nodes, not executed HTML. Templates are marked examples. The page clears stale output on edits, hidden-page transitions and a 60-second observation limit; downloads re-check. Clearing the page cannot delete previously downloaded files, and lifecycle events are not a guaranteed process-memory erasure mechanism.

Drafts and prepared requests contain caller-selected terms and may be sensitive even when prepared for eventual public contribution. Assessment exports omit term bodies, input URLs and filenames but contain their hashes and selected step labels. Hashes are not anonymization; a predictable low-entropy input can be guessed. Keep outputs private unless intentionally published with appropriate authority.

The CLI does not read environment credentials, connect to the network, import the web runtime, or run a task. It rejects symlink/nonregular inputs, bounds reads, and writes new outputs atomically with mode 0600 without overwriting existing files. The caller must choose an appropriately private directory; no security claim is made for a parent directory controlled by an adversary. Errors use fixed reason fields, not raw paths or tracebacks. A blocked but structurally valid assessment is saved with exit 2; malformed input does not create output. I/O failures return exit 3.

A local plan can be regenerated without changing any live ledger because it is explicitly hypothetical. That must never be used as a way to reset actual spent/unknown exposure, restart a task identity, or free active operations. Actual dispatch still belongs to the existing WorkController and its durable sealed custody. The rehearsal does not enforce a process wall-clock deadline, measure third-party compute, account an identity lifetime, price energy/tokens/money, guarantee network cancellation, or prove all required future operations were included by the caller. It checks the selected plan only.

Machine use

The machine guide supplies the schema and exact source download. In the full project, no dependency installation is needed beyond the existing Python environment:

python3 scripts/concresca_work_plan.py template --output plan.json
python3 scripts/concresca_work_plan.py assess plan.json --output assessment.json
python3 scripts/concresca_work_plan.py request plan.json --output request.json

The default template is not ready for publication. An authorized agent edits its selected terms, real dates, resource bounds and publication declaration. The request command creates an envelope only after valid assessment; it never sends it. Existing output files cause a nonzero result rather than being replaced. For stand-alone use, retrieve the three source files linked from the guide: the planner, existing wire validator, and existing resource ledger. This is a plain Python path, not a human approval workflow.

Validation

The selected local suites passed: 42 new Python tests, 88 Node tests, 16 Chromium interaction scenarios, 16 prior workbench Python tests, 40 prior workbench Node tests, and 275 existing work/budget/controller/read/client tests. The 88 Node tests include 78 browser/Python parity vectors: 14 specific edge cases and 64 deterministic randomized plans generated by the actual Python ledger implementation. These are test counts, not coverage percentages.

The 42 new Python tests cover valid and blocked plans, unknown/retry exposure, cleanup isolation, slot limits, expiry, absent publication declaration, duplicate/malformed JSON, exact digest/wire compatibility, atomic output protection, CLI codes, static route ownership, MIME/HEAD responses, source-download parity, no-script markup, navigation and generator drift. Four cases exercise the actual existing owned WSGI handler with an isolated SQLite test adapter. They do not establish production MySQL behavior.

The 16 browser interaction cases exercise actual packaged markup, CSS and application logic mounted offline: immediate actions and clear block reasons, prepare/export, editing, cancelled stale asynchronous results, hostile text imports, duplicate JSON, slot exhaustion, expiry/visibility invalidation, output downloads, add/remove/clear, keyboard and mobile layouts down to 320 CSS pixels. Neither fixtures nor screenshots are published as real work activity.

Browser boundary: environment policy blocked native localhost navigation with ERR_BLOCKED_BY_ADMINISTRATOR. Tests therefore mount the page offline, remove CSP/module imports only in the fixture and supply a SHA adapter. This does not prove native ESM delivery, CSP enforcement or browser WebCrypto on the hosting server. Native module hashing is tested separately under Node WebCrypto; packaged route/MIME behavior is tested separately through the existing static responder. A JavaScript-disabled offline navigation attempt stalled and was not counted as a pass; fallback markup is checked statically. No browser policy was bypassed. An initial old-workbench test invocation omitted its required fixture environment variable; it failed before assertions, then the documented fixture setup and all 40 tests passed.

Evidence: new Python transcript, Node/parity transcript, browser record, existing work suite, prior workbench Python, prior workbench Node, and validation summary. Final archive verification is provided alongside the delivered ZIPs, separately from these pre-packaging records.

Preserved

The r9 Python runtime, dispatcher, automatic verifier, receipt validator, activation/diagnostic machinery, migrations, protected client and budget ledger are unchanged. Fingerprint-bound discovery documentation and the existing work-contract JSON are unchanged. No new credential, database migration, server route, host rule or scheduler is required. The existing static coordination/developer route prefixes already serve the new files.

Navigation-only changes to the Collaborate landing page and generated work guide are recorded by a chained preservation amendment, retaining the original baseline and previous edition's amendment byte-for-byte. Edition change inventory records every new/changed public path relative to Site Improvements 1. The private package retains all original report custody, original intake decisions and protected doctrine. Updated typed memory owners link implemented details, sources, limits, validation and remaining work. Generated exports are rebuilt from those owners.

Deployment is a complete root archive over the existing document root, not a partial overlay or a clean-delete installation. Preserve root .htaccess, private environment, Python environment, database, runtime receipts/state, worker schedule, credentials and diagnostic-code directory. Do not restart Python or run activation solely for this client/docs edition. The separate complete private source/memory archive belongs outside the webroot. No live deployment was performed in this task.

Remaining

All sixteen source-level kept-active dispositions remain open. This implementation advances bounded planning, task preparation and usable machine equivalents; it does not complete durable lifecycle metering, native SQL concurrency, rights/dependency propagation, actual connected ChatGPT acceptance, independent useful-work pilots or unattended production renewal observations. Earlier code may already implement parts of those areas; the retained source-specific next actions define what evidence is still missing.

A locally accepted request and a successful plan are not proof that the work was executed, that an external artifact is correct, that a provider accepted terms, or that a requester approved a delivery. Actual publication, protected dispatch, resulting acceptance and live browser readback remain separate observations. No historic passing report is converted into a new readiness receipt.