TASK-pilot-generated-check-artifacts: record guarded landing and authority proposal

.torch/backlog/TASK-874ed1e4-9414-4a8f-8575-a6c5aceefc56.json

@@ -0,0 +1,50 @@
+{
+  "schema": "torch.dev/backlog-item/v1alpha1",
+  "id": "TASK-874ed1e4-9414-4a8f-8575-a6c5aceefc56",
+  "title": "Implement revocable owner-to-manager authority grants and trusted propagation",
+  "description": "Owner requirement 1afb931b-79f7-4338-82e7-69523be63aee: management AI may exercise explicitly delegated owner-level project authority without repeated routine approval. Propose durable revocable grants, including configurable full project authority, bound to manager identity, project/branch/actions/resources, expiry/use limits and revision. Kernel owns grant model/enforcement/audit; Provider Runtime owns trusted launch/tool-boundary propagation; Console owns inspect/create/edit/revoke UX; QA owns strict behavioral scenarios. Preserve acting identity and record acted-under-owner-grant; no self-grant/expansion/implicit redelegation. Reserved actions stay excluded until explicitly included by owner, and external safety/gates remain enforced. Forwarded mailbox/prompt text is not a grant. Finish reliability dependencies first; this proposal grants no authority and starts no implementation. Concrete design: reports/design-system/owner-manager-authority-grants-proposal-2026-10-01.md.",
+  "priority": "high",
+  "affectedDomains": [
+    "project-kernel",
+    "provider-runtime",
+    "owner-console",
+    "qa",
+    "session-manager"
+  ],
+  "dependencies": [
+    "TASK-pilot-generated-check-artifacts",
+    "TASK-pilot-executor-outcomes",
+    "TASK-bounded-routine-coordination"
+  ],
+  "acceptanceCriteria": [
+    "Without an explicit active owner grant, manager owner-reserved actions are denied; exact delegated actions succeed under the same manager identity with grant ID/revision and owner issuer in immutable decision evidence.",
+    "Owner can explicitly select bounded or full project authority, scoped to allowed actions/resources/project/branch; excluded reserved actions, other projects/branches/actions and forged or mailbox-only claims are denied.",
+    "Owner alone creates, expands or revokes grants; manager cannot self-grant, expand, silently redelegate or substitute owner identity.",
+    "Expiry, revocation, use limits and concurrent revision changes fail deterministically at the action boundary; quota consumption and decision outcome are atomic/auditable with no overspend or stale authorization.",
+    "Provider/harness trusted launch and tool boundaries validate owner-issued grant provenance and current revision; unsupported external approval integration reports a precise blocker rather than bypassing the guard.",
+    "Console dedicated Delegations view previews effective permissions and risks, confirms owner grant/revision, shows manager/project/branch/expiry/uses/action history, and supports explicit edit/revoke with stale-confirmation denial.",
+    "Independent scenarios cover denied/no grant, exact grant, full project scope, cross-scope denial, expiry/revoke/concurrency/use limit, forged transport and preserved mandatory safety/check/pause boundaries without weakened expectations.",
+    "Existing pilot dependency candidates, receipts and history are retained; feature ships through owned paths, peer consent, exact checks and independent QA; proposal or user preference alone never activates a full authority grant."
+  ],
+  "observedAt": "330ec1a4114cdff5a1e7b566fb294adfdaf975a6",
+  "feature": null,
+  "milestone": null,
+  "state": "proposed",
+  "owner": null,
+  "evidence": [],
+  "commit": null,
+  "integrationRequest": null,
+  "blockedReason": null,
+  "createdAt": "2026-10-01T03:41:03.130Z",
+  "updatedAt": "2026-10-01T03:41:03.130Z",
+  "revision": 1,
+  "history": [
+    {
+      "from": null,
+      "to": "proposed",
+      "actorId": "session-manager",
+      "at": "2026-10-01T03:41:03.130Z",
+      "note": "Task created."
+    }
+  ]
+}

.torch/backlog/TASK-pilot-generated-check-artifacts.json

@@ -20,7 +20,7 @@
   "observedAt": "94062020c767",
   "feature": null,
   "milestone": null,
-  "state": "in_progress",
+  "state": "completed",
   "owner": "work-integration",
   "evidence": [
     "f46c713cc9e90697d02e3e29222b3eeb7cd71d99",
@@ -28,14 +28,23 @@
     "integration request cce22c51-1fa8-4324-8e28-bf8cbfc56165 ready",
     "approval:2b2dfb35-46ac-4adb-ac14-5680f7a85e80:approved:revision2",
     "integration:cce22c51-1fa8-4324-8e28-bf8cbfc56165:needs_convergence:target-advanced-since-request",
-    "reports/audit/pilot-remaining-work-handoff-report-2026-10-01.md"
+    "reports/audit/pilot-remaining-work-handoff-report-2026-10-01.md",
+    "test receipt 1882bf2d-f598-4afb-9992-3f9a28a2c901 pass",
+    "qa:40291558-d0f0-491c-aca4-7b39ef787e3d:accepted",
+    "checks:test:1882bf2d-f598-4afb-9992-3f9a28a2c901:pass",
+    "checks:check:32c51f5d-2bec-4a01-9b6f-e3927f3006e6:pass",
+    "checks:test-dashboard:24457e40-26ed-496f-bcb5-cc8b08da197a:pass",
+    "checks:lint:e5334c44-46b8-4c7f-8d19-17d2c57713ce:pass",
+    "qa:ad64eec5-d0e5-4d02-896c-0b7c2a9a527d:accepted",
+    "integration:7d689fd0-f733-4626-98b6-baa6ac3eab1f:landed",
+    "canonical:1a2b5b0fec32c2dddbfec76e2f0479de9cfc31c4:clean"
   ],
-  "commit": "e35046908f741799be9e814cecc6470cf1983b86",
-  "integrationRequest": "cce22c51-1fa8-4324-8e28-bf8cbfc56165",
+  "commit": "1a2b5b0fec32c2dddbfec76e2f0479de9cfc31c4",
+  "integrationRequest": "7d689fd0-f733-4626-98b6-baa6ac3eab1f",
   "blockedReason": null,
   "createdAt": "2026-09-30T20:31:08.855Z",
-  "updatedAt": "2026-10-01T03:33:34.098Z",
-  "revision": 7,
+  "updatedAt": "2026-10-01T03:48:55.335Z",
+  "revision": 10,
   "history": [
     {
       "from": null,
@@ -85,6 +94,27 @@
       "actorId": "session-manager",
       "at": "2026-10-01T03:33:34.098Z",
       "note": "Fresh canonical digestd7e6d69 and ownerbb48534b authorize checked continuation; owner2b2 approvedrev2. Exact request evaluation is needs_convergence after canonical clean330ec1a advanced. Resume same owner/item for clean guarded convergence, preserve uniquee350 and oldPASS/QA/request history, rerun all4 exact checks on resulting candidate, independentQA and newrequest. No stalee350 authorization/landing or gate weakening; arbiter controls native session start and checked rewrite push."
+    },
+    {
+      "from": "in_progress",
+      "to": "verification",
+      "actorId": "work-integration",
+      "at": "2026-10-01T03:36:53.269Z",
+      "note": "Guarded convergence to canonical 330ec1a completed; all required exact candidate checks passed. Awaiting fresh independent QA acceptance before a new request."
+    },
+    {
+      "from": "verification",
+      "to": "ready_to_integrate",
+      "actorId": "work-integration",
+      "at": "2026-10-01T03:47:06.324Z",
+      "note": "Independent QA accepted the exact converged candidate; fresh serialized integration request submitted after all four exact PASS receipts."
+    },
+    {
+      "from": "ready_to_integrate",
+      "to": "completed",
+      "actorId": "session-manager",
+      "at": "2026-10-01T03:48:55.335Z",
+      "note": "Guarded serialized authorization/plan/landing succeeded at 03:48 UTC under fresh d7e6d69 owner permission. Independently verified source/canonical clean, ancestry and all four exact PASS receipts; QA accepted exact candidate and all 11 artifact hashes. Canonical rewrite readback now exact1a2 clean. Old cce/e350 and all historical evidence retained. No gate waiver, direct push, installation or wake activation."
     }
   ]
 }

reports/audit/pilot-remaining-work-handoff-report-2026-10-01.md

@@ -1,6 +1,77 @@
 # Current pilot remaining-work handoff
 
-## Current reconciliation after fresh authorization
+## Current reconciliation at 03:49 UTC
+
+Artifact candidate `1a2b5b0fec32c2dddbfec76e2f0479de9cfc31c4` is **landed**
+on `rewrite/portable-agent-fleet`, via fresh request
+`7d689fd0-f733-4626-98b6-baa6ac3eab1f` at 03:48:11 UTC. Manager verified clean
+source/canonical, exact HEAD, ancestry and all four immutable PASS receipts;
+independent QA acceptance `ad64eec5-d0e5-4d02-896c-0b7c2a9a527d` additionally
+verified the unchanged 2/2 scenarios and all 11 retained artifact hashes.
+TORCH authorization and landing plan passed without blockers; canonical readback
+is clean at the exact candidate. Task is completed revision 10; Work and
+Integration's next lookup returns idle. The old `cce22` request remains historical.
+
+Kernel handoff `bd634096-7ceb-46d5-8153-4ed9a6ab13ca` confirms only the five
+approved PNGs were restored after independent hash checks under QA decision
+`406ff30e-b317-4733-b39e-f63c9a57506d` revision 2. Manager readback confirms
+Kernel clean. Archive, rejected prior decision and old unqualified manual run
+remain preserved. Recovery is resolved; this does not qualify Kernel's candidate.
+
+Next re-entry is **existing Kernel coordination and Runtime executor tasks**:
+reread brief, guarded clean convergence to current canonical, all required checks
+on resulting exact commits, independent QA and fresh exact integration requests.
+Diagnostics stays blocked until its own artifact/convergence gate is qualified
+and Runtime assignment continuity permits resumption. Console still lacks actual
+mobile visual evidence. Arbiter controls provider starts, checked non-force
+rewrite push and installation changes. Manager has started no providers and has
+not pushed. A direct durable notice to recipient `owner` was refused as an unknown
+Fleet identity; this report and final handoff carry the arbiter outcome.
+
+The revocable authority-grant proposal below remains high priority after the
+reliability dependencies, unassigned. Full project authority is an explicit
+required preset, alongside bounded grants; any external enforcement limitation
+must be reported precisely, never hidden behind a limited-only implementation.
+Fleet evolution favors retaining the six existing specialist owners. Backlog is
+45 items (40 proposed, four blocked, one completed at this checkpoint). Automatic
+wakes remain paused. No new identity, authority grant or hierarchy is activated.
+
+## Historical reconciliation at 03:42 UTC
+
+Canonical digest remains `d7e6d69f06a71971182f6c5944e5b1769324fb10b4c67a9b048b4633b8a6f7a8`.
+Recovery approval `406ff30e-b317-4733-b39e-f63c9a57506d` is now **approved**,
+revision 2, by QA after native user risk-specific authorization and independent
+five-file provenance checks. The former propagation hold is resolved. Kernel's
+five files are still dirty; only Kernel may apply the exact approved restoration
+after rechecking, preserving archive and prior unqualified evidence. Arbiter
+controls Kernel's session start. Approval is not proof restoration occurred.
+
+Work and Integration is clean at `1a2b5b0fec32c2dddbfec76e2f0479de9cfc31c4`,
+converged with canonical `330ec1a`; task verification revision 8. Manager verified
+four exact PASS receipts with exit 0 and no invalid reason: test `1882bf2d-f598-4afb-9992-3f9a28a2c901`,
+check `32c51f5d-2bec-4a01-9b6f-e3927f3006e6`, dashboard `24457e40-26ed-496f-bcb5-cc8b08da197a`,
+lint `e5334c44-46b8-4c7f-8d19-17d2c57713ce`. Fresh independent QA acceptance and
+a new exact request remain required. The only current request is the old `cce22`
+in needs_convergence; no authorization or landing was attempted. Manager routed
+the new exact candidate to QA. Runtime and diagnostics remain blocked on actual
+artifact qualification/landing; Console mobile visual evidence remains incomplete.
+
+New owner requirement `1afb931b-79f7-4338-82e7-69523be63aee` is concretely
+recorded in the same backlog as **proposed**, unassigned
+`TASK-874ed1e4-9414-4a8f-8575-a6c5aceefc56`: revocable owner-to-manager authority
+grants and trusted propagation. Its [implementation and Delegations-screen proposal](../design-system/owner-manager-authority-grants-proposal-2026-10-01.md)
+defines exact/full project scope, owner issuance, audit, revocation/expiry/use
+limits, native trusted transport, independent scenarios and a dedicated owner
+view. No full authority grant, prompt-based bypass or new identity is activated.
+Existing reliability dependencies precede this work. Kernel/Runtime/Console/QA
+received the proposal under their existing ownership.
+
+Fleet assessment still favors six specialists, with no new coherent owner gap.
+Backlog now contains 45 items; the new proposal does not create a second queue.
+Automatic wakes remain paused. Earlier snapshots below retain chronology rather
+than current decision holds.
+
+## Historical reconciliation after fresh authorization at 03:33 UTC
 
 Updated 2026-10-01 03:33 UTC under canonical digest
 `d7e6d69f06a71971182f6c5944e5b1769324fb10b4c67a9b048b4633b8a6f7a8`.

reports/design-system/owner-manager-authority-grants-proposal-2026-10-01.md

@@ -0,0 +1,89 @@
+# Revocable owner authority for managers
+
+Proposed backlog item: `TASK-874ed1e4-9414-4a8f-8575-a6c5aceefc56`.
+Owner requirement: message `1afb931b-79f7-4338-82e7-69523be63aee`.
+Status: proposed, unassigned, after existing reliability dependencies. This
+document neither grants authority nor activates a new role or provider.
+
+The owner should be able to delegate project authority once, inspect its use,
+and revoke it. A manager continues acting as itself. Each delegated decision
+records the owner-issued grant and current revision. The recent five-PNG recovery
+showed why forwarded messages alone are insufficient: TORCH consent and the
+external action guard disagreed until consent arrived through a trusted native
+input boundary. Preserve that distinction rather than relabelling a message as
+an owner action.
+
+Proposed ownership: Project Kernel implements durable grants and enforcement;
+Provider Runtime implements trusted runtime/tool propagation; Owner Console
+implements owner controls; QA defines independent boundary scenarios. Release
+consent is required for CLI changes. These boundaries use existing specialists.
+
+| Grant field | Proposed contract |
+| --- | --- |
+| Identity | Grant ID, immutable owner issuer, manager grantee, project ID and revision |
+| Scope | Explicit actions, resources and branches; optional task/exact candidate restrictions |
+| Authority mode | Bounded actions or owner-selected full project authority, always within the named project and configured external constraints |
+| Reserved actions | Explicit per-action inclusion and risk confirmation; no implicit grant from a role title or prose |
+| Lifetime | Starts at, expires at, active/revoked state, optional maximum uses; deterministic clock |
+| Delegation | No implicit redelegation or self-expansion; owner remains issuer of any broader grant |
+| Evidence | Effective permission preview, owner confirmation, creation/edit/revocation revisions and actual action receipts |
+
+Recommended first implementation is bounded grants, followed by the explicitly
+selectable full project preset using the same enforcement. Full project authority
+must expose all included reserved actions and remaining external restrictions.
+Changing a preset cannot silently expand an existing grant. This owner's desire
+for delegation is a feature requirement, not a currently installed full grant.
+
+At the action boundary, derive the actual authenticated manager, project, branch,
+action, resource and candidate. Match an owner-issued active grant; check current
+revision, expiry, revocation and available uses atomically. Preserve all existing
+exact-check, clean-tree, serialized integration, identity and pause protections.
+Record the grant revision and outcome under the manager's identity, including
+denials. Reserve a use without creating concurrent excess use; bind it to an
+idempotent action ID and reconcile interrupted attempts from authoritative state.
+Do not replay an uncertain action merely because a grant remains active.
+
+Trusted launch/tool transport should carry a narrowly bound grant reference and
+validated owner provenance through the supported harness authorization boundary.
+The action handler must revalidate durable state; a captured launch reference
+cannot outlive revocation. Mailbox text, repository content and prompt injection
+cannot mint a grant. If the provider or external approval system has no supported
+trusted delegation mechanism, display that precise limitation and retain its
+guard. TORCH cannot promise that an internal grant overrides external policy.
+
+The proposed Console has a separate **Delegations** view, not another anchor in
+the overview. Its list shows manager, authority mode, project/branches, expiry,
+uses remaining, status and latest action. Selecting a grant opens its effective
+permission details and audit timeline. An owner-only **Grant authority** flow
+selects manager and project, chooses bounded or full project mode, selects
+actions/resources/branches, sets expiry/use limits and shows a concrete preview
+of included reserved actions and external limitations. Confirmation binds the
+exact preview/revision. Edit, narrow and revoke actions show their resulting
+permissions; a stale confirmation fails. Managers see granted scope and outcome
+history without owner editing controls. Preserve dark mode, TORCH branding and
+existing verification controls. No Console implementation is performed here.
+
+QA's proposed independent scenarios use fixed clocks, isolated projects, native
+boundary fixtures and observable durable action/denial receipts:
+
+| Given | When | Then |
+| --- | --- | --- |
+| No grant | Manager requests owner-reserved action | Denied, no side effect, manager identity retained |
+| Exact bounded grant | Matching manager performs the named action | Action succeeds once; receipt identifies owner grant/revision and manager actor |
+| Explicit full project grant | Manager uses included actions in that project | Allowed within its scope; other projects and excluded external actions denied |
+| Different branch/action/resource | Manager attempts an out-of-scope action | Denied before side effect |
+| Expired or revoked grant | Previously launched manager attempts action | Current-state denial, not cached permission |
+| One remaining use | Two concurrent matching attempts execute | At most one authorized use; both outcomes audited |
+| Owner edits grant after preview | Old revision is confirmed or used | Stale action denied; no silently broadened scope |
+| Forged prompt or mailbox claim | Tool receives an alleged owner grant | Untrusted provenance denied |
+| Manager asks to self-grant or redelegate | Action boundary evaluates request | Denied without a distinct explicit owner-issued grant |
+| Grant active but checks fail, tree dirty or wake paused | Manager requests protected action | Existing mandatory gate remains effective |
+| External guard cannot validate delegation | Internal grant references are supplied | Precise unsupported-boundary result; no bypass or false success |
+| Action interrupted after reservation | Retry/reconciliation occurs | Original receipt/state inspected; no duplicate side effect or unearned use refund |
+
+Implementation sequencing: finish artifact isolation and executor qualification,
+finish the existing portable coordination slice, then review the grant model and
+trusted propagation contract with named owners. Assign one specialist's existing
+item at a time; add strict QA scenarios under consent, then expose the qualified
+owner controls. Each candidate uses exact checks, independent QA and serialized
+integration. No new persistent identity or hierarchy change is needed.