Files
jobtrackingapp/docs/automation/ACTIVATION_01.md
T

8.9 KiB

AUTO-ACTIVATION-01 — blocked before activation

30 October 2026. P10-00 execution remains NO-GO. The command-running composite application adapter is not qualified inside the existing security boundary. The queue remains disabled and operator-controlled. No autonomous/model session, owner signature, Phase 10 assessment, product edit, migration, main merge or deployment was performed.

What is verified

Deliverable Result
Composite application adapter BLOCKED. Existing command-running provider/browser/Python/PDF/security/preservation adapter remains configured:false. The new evidence-inspection utility is deliberately prevented from being marked runtime-qualified.
Real application evidence Existing published handoff verifier passes. Its 34 native report records, exact process exits, original test membership, source bindings and conditional decisions are preserved. A receipt freezes 3,483 non-envelope source files. These are reused executions, not newly run product suites.
Controller tests 81 distinct tests pass, zero failures/errors/skips, source stable. Includes the original 69, twelve assessment tests, cryptographic approval/resume, missing-approval refusal and disposable-Git protected-stop simulation. Do not add focused reruns to 81.
Native sandbox Current installed real-key/files/network canaries PASS. Separately tested projected assessment profile: source read succeeds, source write/delete fail, report creation succeeds; frozen-source/evidence inspection succeeds inside MXC.
Authentication Installed auth-status reports CHATGPT_SIGNED_IN. No tokens copied/read; account identity and a live model request were not verified.
Owner signing Existing nonexportable key retained. Pinned public certificate matches, host signing positive control succeeds and worker access to that actual key is denied. No replacement owner key or owner approval was created.
Exact product baseline fc5b9d377199ce51f480a920a3772108094929e3, published as the direct parent of 5cb903b989742b7a96cb22ddf4c0e24993b18980.
Published handoff Fresh remote test/pre-phase10-ux-acceptance equals 5cb903b989742b7a96cb22ddf4c0e24993b18980. Parent/envelope changes are confined to the handoff directory. No baseline substitution.
Execution checkout C:\Users\Connor\.codex\worktrees\p10-assessment\Job tracker, branch codex/p10-assessment-ready, exact baseline and clean Git index/worktree. 47 checkout line-ending differences were materialised as exact accepted bytes; each Git blob was checked identical before refreshing index stat information.
Policy Disabled proposal prepared, preserving all seven stages/order. P10-00 scope is explicitly assessment-only with protected candidate-specific-cleanup-scope stop. Latest handoff decisions are pinned supplemental prompt content.
P10-01 Hard rejected outside the P10-00 execution cap, even with generic synthetic approvals. Its implementation adapter remains unconfigured. A new exact owner-controlled implementation policy and runtime qualification are required.
Actual state Zero roadmap sessions, no recovery needed, no scheduling. Existing installed repository and baseline policy remain unchanged; the clean execution checkout has not been selected or activated.

The remaining runtime blocker

Native probes used the existing MXC policy without widening permissions:

  • Docker cannot read the owner's Docker configuration or access docker_engine. Giving an autonomous worker the general host Docker socket would undermine the isolation boundary.
  • The accepted user-local .NET executable cannot resolve its executable under this profile. The separately installed system .NET runtime starts but reports no SDKs; that is not a passing backend test run.
  • The accepted Docling virtual environment, outside the worker checkout, cannot resolve pyvenv.cfg under the current profile. Starting the normal isolated Python interpreter is not Docling qualification.
  • Worker network access, including loopback, remains denied. Real browser/API/MariaDB test services have not been qualified through a bounded isolated executor.

The accepted command catalogue includes the actual backend/frontend/build/browser/MariaDB/Python/Docling/CV/PDF commands and their native exits/membership. It is an inventory of previous executions, not an installed test runtime. Security, human/device, hosted CI, model and production limitations remain separate and unchanged. Existing PDF/S01 acceptance was not reopened.

Completing AUTO-ADAPTER-01 requires a qualified test executor that can run these exact applicable commands against disposable services without exposing the owner's general Docker socket, files, signing key or production resources to the worker. That executor is not implemented/qualified by this change. Do not turn configured on, approve evidence reuse as a substitute, or run enable-unattended, start or resume to bypass it. A second account, subscription or VM has not been prescribed.

Prepared policy and protected requests

Installed proposal:

C:\Users\Connor\.jobjakt-backlog\single-user-local\proposed-p10-assessment.json

Review copy: automation/qualification/p10-assessment.policy.json.

The controller has generated one genuine unsigned disabled manifest-policy-update request:

C:\Users\Connor\.jobjakt-backlog\single-user-local\requests\d637caf72c3fed5910f7c28e75dc82324d8febc12597ddb5627ae022af49a622.json

It binds the proposed manifest hash. Its baseline field describes the currently installed old policy, not acceptance of that old product baseline. The proposed manifest names the correct fc5b9d3 baseline and separate 5cb903b envelope. Even approving/adopting this proposal would leave execution disabled and adapters unqualified. No owner action on this request is necessary while the runtime blocker remains.

Environment, roadmap, Phase 10 entry and restricted-execution requests were not made eligible or signed. Generating misleading eligible requests before mandatory adapter qualification would bypass the handoff gate. Valid future approvals must bind the final installed policy/code/configuration, correct execution checkout, baseline/envelope, full prompt hashes, qualified runtime reports and exact scope. Changing those inputs invalidates applicability.

The prepare-entry command is implemented to prepare successive protected entry requests without launching a worker. It requires an adopted enabled restricted policy, fresh qualified runtime, clean exact baseline and configured adapters. It refuses the current disabled queue with native exit 2 and zero sessions. The RTK wrapper may map nonzero child exits to 1.

When the actual runtime blocker is resolved, the existing protected sequence remains: configure the genuinely qualified final manifest, owner approve, configure the same exact file, refresh qualification after real config changes, owner enable-unattended, then prepare-entry / owner approve until the exact grants are verified. Each grant authorises only its requested scope: environment evidence; exact capped policy; Phase 10 entry; restricted P10-00 assessment. The owner then deliberately invokes start. There is no safe activation command for the present unqualified manifest.

Commands safe to run now

. "$HOME\.jobjakt-backlog\single-user-local\Use-JobjaktBacklog.ps1"
Jobjakt status
Jobjakt auth-status
Jobjakt dry-run

dry-run should still report execution disabled and the unqualified composite adapter. The existing owner key/authentication setup needs no repetition. The refreshed qualification is valid only for its recorded code/config binding and 24-hour window; retargeting to the execution checkout or adopting the restricted profile needs the applicable requalification.

Evidence

  • automation/reports/activation/results.json and tests.txt: 81 current tests and exact source hashes.
  • automation/reports/activation-native.json: real restricted-profile/key/source/evidence probes.
  • automation/reports/activation/control-state.json: disabled queue, zero sessions, public pin and current installed binding checks.
  • automation/reports/activation/entry-rejection.json: actual no-execution entry refusal.
  • automation/reports/activation/accepted-command-catalog.json: prior genuine command/process/report identities; no new product execution claim.
  • automation/reports/activation/tool-probes.json: actual runtime capability failures.
  • automation/reports/activation/schema-validation.json: manifest constraints checked with existing Ajv; Draft 2020 meta-schema validation was unavailable. Runtime manifest validation also passes.

Earlier failed development-test attempts were corrected; the final 81-test run supersedes them. Historical product totals and original PDF oracle failures remain intact. No new PDF export, model inference, provider suite, human/device check, hosted CI or production qualification was performed.