feat(automation): enforce assessment scope and document activation blockers

This commit is contained in:
cesnimda
2026-10-30 09:40:12 +01:00
parent 140e182516
commit 750d76317c
22 changed files with 7065 additions and 12 deletions
+80
View File
@@ -0,0 +1,80 @@
# 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:
```text
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:
```text
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
```powershell
. "$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.
+15
View File
@@ -0,0 +1,15 @@
# AUTO-ACTIVATION-01
Implement the owner's 30 October activation request in the existing isolated tooling worktree. Stop before execution or signing. Preserve the existing key/authentication, seven workstream order and all later gates.
- [x] Resolve published handoff 5cb903b and its direct parent candidate fc5b9d3; keep their identities separate.
- [x] Check existing authentication and native real-key isolation. Docker pipe access is correctly denied; no system .NET SDK. Do not widen service access.
- [x] Inspect source-bound evidence using the existing handoff verifier, exact native report membership and frozen source hashes. Retain conditional/security/human dispositions. Evidence inspection is explicitly prevented from substituting for the mandatory command-running composite adapter.
- [x] Add a restricted P10-00 policy, report-only filesystem permissions and independent write-set verification. Reject P10-01 regardless of a generic roadmap signature. Test missing approvals and the protected stop using disposable Git remotes.
- [x] Prepare a clean execution checkout at fc5b9d3, exact unsigned disabled-policy request and an owner command for preparing successive eligible entry requests without launching a worker.
- [x] Run existing controller tests, new adapter/scope tests and native assessment probes; preserve their distinct evidence. Document remaining owner actions.
- [ ] AUTO-ADAPTER-01 remains BLOCKED: command-running application/service runtime not isolated and qualified. Stop before activation; do not expose general Docker/socket or widen worker access to bypass this barrier.
Ruling: the evidence-reuse inspector cannot satisfy the owner's explicit real composite runtime gate. Keep proposed and installed policies disabled, retain configured:false, and do not generate eligible environment/entry grants. The 81-test final run and native probes qualify control-plane changes only, not actual roadmap readiness. See ACTIVATION_01.md.
Changes reach controller and installed packaging, local filesystem policy, manifest schema, evidence adapter, PowerShell command dispatch, tests and operator documentation. Product files, existing acceptance evidence and the signing key remain outside the change scope. The adapter uses the existing trusted handoff verifier to prepare a receipt, then verifies exact immutable evidence/source bytes; this avoids a second report parser and unnecessary product reruns. Fresh provider runtime qualification remains a separate barrier to implementation.
+3 -1
View File
@@ -1,5 +1,7 @@
# Run from your existing Windows and ChatGPT account
**30 October 2026:** see [current activation status](ACTIVATION_01.md) before activation. Existing authentication and owner-key setup are verified; do not repeat them. The real composite runtime remains unqualified and the queue remains disabled.
`single-user-local` removes the second Windows-account/VM requirement. It keeps the original queue, signed decisions, Git guards, recovery, locking and finite resource budgets. **Phase 10 and the actual roadmap remain disabled.** The current accepted development baseline is still an explicit policy decision, not something setup infers from main.
## Setup once
@@ -104,4 +106,4 @@ It uses your existing login, limited privileges, logon plus 15-minute continuati
Real canaries verify the tested native-worker boundaries. They are not an exhaustive proof against every Windows API, credential provider or future sandbox defect. Unrestricted applications running under your same Windows identity are outside the worker boundary and can still act as you. This is not equivalent to an independently administered account/VM. Apps, plugins, MCP and web search remain disabled in this mode; a later security scan/provider task needing them must pause for independently qualified capabilities, not silently enable your normal configuration.
At handoff: setup and canary qualification have been exercised under the current login; the dedicated home is **not signed in**, the real owner key is **not configured**, operation is **operator-controlled**, and the queue is **disabled**. See [acceptance and evidence](SINGLE_USER_ACCEPTANCE.md). Your next steps are the same-account `auth`, operator `key`, and real-key `qualify` commands; actual roadmap activation still waits for formal Phase 10 entry.
The initial AUTO-02 [acceptance snapshot](SINGLE_USER_ACCEPTANCE.md) predates the owner's sign-in and real-key setup. Those missing-auth/key statements are historical; [ACTIVATION_01.md](ACTIVATION_01.md) records the verified current setup and remaining runtime blocker. Operation is still operator-controlled and the queue is disabled.
+2
View File
@@ -1,5 +1,7 @@
# Autonomous roadmap follow-up
30 October AUTO-ACTIVATION-01: pre-Phase-10 preparation is conditionally closed at published handoff `5cb903b`; proposed product baseline remains its parent `fc5b9d3`. Existing owner key/authentication and real-key isolation are verified. **Activation remains blocked by the real command-running composite runtime.** See [ACTIVATION_01.md](ACTIVATION_01.md) for current evidence and safe commands; the historical provisioning bullets below do not supersede that report.
AUTONOMOUS-ROADMAP-02 adds the normal-login route in [SINGLE_USER.md](SINGLE_USER.md). Single-user setup and native canary qualification are implemented; the real owner key, same-account sign-in and Phase 10 authorization remain owner actions. The separate-account provisioning below is now optional; single-user MXC qualification is the alternative.
Implementation checkpoints AUTO-00–08 are complete in the qualified scope described in ACCEPTANCE.md. The following are deliberately **not authorized/completed** by installing the controller: