Request lifecycle acceptance
request-lifecycle.mjs is an opt-in submission/observation runner for a later
lead-authorized isolated instance. It uses the existing owner process proof and
the running production host. It does not start a host, launch a scripted role,
select resources or a mode, approve a PRD, mint credentials or provision services.
Prepare a named development instance with its matching instance.json, an
existing factory source, installed tracker board and scoped credentials, and
real PM, CTO, chief, coder, reviewer and assistant routes. Start that instance
through the supported entry points in the authorized window. The owner supplies
an existing assistant thread. The runner requires an explicit instance, config,
business, expected owner, request quotation and evidence output directory.
--owner checks the configured identity; it does not authenticate anybody.
Example with deliberate placeholders (replace every uppercase value):
node packages/cli/live/request-lifecycle.mjs \
--instance pomo797 --config /ABS/CONFIG.json --business BUSINESS --owner OWNER \
--thread THREAD_UUID --submit --authorize-isolated-run \
--request-file /ABS/pomodoro-request.json --evidence /ABS/EVIDENCE
The owner selects and confirms the exact displayed plan in the signed-in Console.
Autonomous PRD approval remains with the distinct technical arbiter. Guided mode
requires the owner's answers and exact-version approval. No owner relays messages,
creates a task manually, or runs worker shell commands. The quotation in
../tests/fixtures/pomodoro-request.json preserves the owner's original wording
and provenance; it is not a raw runtime event export. The new runtime event and
message IDs are retained separately.
The runner retains each observed request revision and final task/review trails.
On complete reviewed delivery it reports the owner-only Console download URL.
Download there, then rerun observation with --request EVENT_UUID and
--artifact /ABS/DOWNLOADED.html in place of --submit --thread THREAD_UUID.
The runner checks the exact reviewed artifact length and SHA-256 and keeps a copy.
Unknown outcomes and timeouts retain evidence and fail; they never trigger a
replacement submission or approval. Output files are created exclusively.
For the lead's live acceptance, retain the original input/message, owner plan confirmation, active approved snapshot, tracker create/assignment, code commit, independent reviewer fetch/test record and verdict, closure, delivery receipt, chief/assistant notification and downloaded bytes. Check that their project, snapshot, task, commit, review and verdict IDs form the same chain. In an offline browser, check the approved proposal's work/break durations, start, pause/resume, reset, phase transition and cue after a user gesture, and no network requests or external assets. The defaults are agent proposals approved in the product PRD. Inspect real independent role/test receipts before declaring live acceptance.
The repository fixture runs a separate runtime process over the same persistent fake tracker and real Store/repositories after each crash. Its scripted models use shipped role authority, launch admission/limits, session manifests, real typed tool subprocesses and Git bundles; coder and reviewer run the committed Node acceptance test independently. It exercises the signed-in HTTP listener and Chromium. It does not demonstrate live model quality or deployment readiness.
Crash restart follows the existing operator recovery rule: there is no automatic stale writer-lock reclaim. The fixture kills and reaps only its own process group, verifies that exact PID is dead, records the stale lock's identity and removes only its lock/socket before restart. The database, WAL and SHM are preserved. A live operator must establish the same facts and preserve evidence before recovery; this harness does not change that production rule.