feat(testing): enforce execution authorization lineage

README.md

@@ -38,6 +38,7 @@ contracts/
   agentic-browser-execution.v1.md
   defect-publication.v1.md
   environment-factory.v1.md
+  execution-authorization-lineage.v1.md
   project-profile.v1.md
   qa-publication.v1.md
   structured-execution.v2.md
@@ -55,7 +56,7 @@ Host repositories compose these packages and provide their own app-specific defa
 
 The formal full-FKST host flow is:
 
-1. The downstream Host creates a product-specific `testing-project-profile.v1`, authenticates one-use approval/preauthorization artifacts, and persists sanitized validation receipts.
+1. The downstream Host creates a product-specific `testing-project-profile.v1`, applies deterministic policy admission to the one-use profile/preauthorization artifacts, and persists sanitized validation receipts. The legacy `approval` schema name does not require a routine human action; the trusted Host policy remains the execution authority.
 2. The Host submits `workflow-qa.run-request.v2` on `workflow-qa.qa_run_request`; product names, commands, URLs, and credential locations remain Host-owned.
 3. `environment-factory` checks out, builds, starts, and publishes the immutable ready environment receipt.
 4. `testing-design` produces repository and traceability context; `workflow-qa` then revalidates the exact browser session through `browser-readiness`.
@@ -93,6 +94,10 @@ Issue seam and durable issue-written acknowledgement to the pinned `github-proxy
 
 Project startup configuration uses the separate `testing-project-profile.v1` and
 `testing-project-profile-approval.v1` contracts documented in `contracts/project-profile.v1.md`.
+Hosts may issue the latter through deterministic machine policy; this package does not require a
+routine human approval step. Removing human interaction does not merge the authority layers:
+profile admission, run preauthorization, Grant verification, and the atomic single-use execution
+claim remain distinct and fail closed.
 Profile validity and canonical digest identity never grant execution permission: a host trust root must
 authenticate the exact approval, and `contract.project_profile.authorize_execution` must recheck the
 profile, immutable repository commit, approval, validation receipt, freshness, and replay claim
@@ -112,7 +117,17 @@ binds `{ url, commit_sha }` repository identity and the sanitized browser readin
 Factory does not start or acknowledge testing. Its production adapter is
 `packages/environment-factory/runtime.lua`, backed by the shell-free Node effect runner at
 `packages/environment-factory/bin/environment-factory-runtime.js`; the hermetic package test drives
-that adapter through real Git, process, readiness, receipt, replay, and cleanup effects.
+that adapter through real Git, process, readiness, receipt, replay, and cleanup effects. All target
+checkout, build, start, readiness, test, and cleanup commands use a private leased home with GitHub,
+Git credential-helper, SSH agent, askpass, hooks, and fsmonitor authority removed. Host command
+environment cannot override those controls, and one-shot leases are removed immediately while a
+supervised-process lease is retained only until verified cleanup.
+
+Those environment controls are defense in depth, not an operating-system sandbox. Every target
+effect also requires the Host-owned `testing-host.target-execution-boundary.v1` contract documented
+in `contracts/target-execution-boundary.v1.md`. The current production package accepts only an exact
+immutable `trusted-fixture-exact` repository binding. Unknown or mismatched repositories fail closed
+with `HOST_RUNTIME_ISOLATION_REQUIRED` until a future Host supplies verifiable OS/container isolation.
 
 Terminal Environment Factory results include an immutable typed cleanup-receipt pointer. The receipt
 lists attempted resources, verified removals, and remaining owner-bound cleanup handles; cross-run

contracts/execution-authorization-lineage.v1.md

@@ -0,0 +1,103 @@
+# Execution authorization lineage v1
+
+`contract.execution_authorization_lineage` defines closed audit receipts for Host-owned authorization
+effects. The receipts let downstream consumers verify the exact authorization chain without turning
+logs, counters, self-digests, or replay handles into an execution capability.
+
+## Boundary
+
+Every exported receipt fixes `evidence_role = audit-only`, `human_approval_required = false`,
+`authorization_capability = false`, `execution_authorized = false`,
+`promotion_authorized = false`, `reusable = false`, and
+`source_max_uses = 1`. It binds one immutable repository commit plus the run,
+trace, and dedup identities. Receipt validators require complete source bindings; shape validation or
+partial caller-provided expectations are insufficient.
+
+The authoritative claim state remains in the Host durable store. Raw claim IDs, fence tokens, state
+MACs, runtime configuration secrets, physical workspace paths, credentials, commands, and capability
+payloads are forbidden from this exported lineage. Each Host profile-policy, authorization-policy,
+attestation, and verifier field fixes one non-interchangeable kind and relative-key grammar; URLs,
+traversal, query, fragment, userinfo, and local
+path syntax are rejected. Claim receipts expose only a domain-separated
+`claim_fingerprint_sha256` computed by the trusted Host from the internal claim handle. A fingerprint
+cannot be submitted to complete or replay the claim.
+
+Possession or validation of a receipt does not authorize checkout, startup, test execution,
+publication, promotion, or a gate effect. Receipts are one-way projections of authenticated Host state,
+never inputs from which authority state may be reconstructed.
+
+## Receipt chain
+
+The fixed chain is:
+
+```text
+testing-project-profile-approval-claim-receipt.v1
+  -> testing-structured-preauthorization-claim-receipt.v1
+  -> testing-structured-execution-grant-verification-receipt.v1
+  -> testing-structured-execution-claim-receipt.v1
+  -> testing-structured-execution-completion-receipt.v1
+  -> testing-execution-authorization-lineage-index.v1
+```
+
+The Profile receipt keeps persisted artifact SHA-256 and canonical Profile/Approval SHA-256 in
+separate named fields. It is emitted only after trusted Approval authentication, point-of-use receipt
+freshness validation, and a successful atomic single-use Profile claim.
+
+The Preauthorization receipt binds the Profile claim receipt, preauthorization, Profile digest, Case
+Catalog, StructuredPlan, ready Environment Receipt, trusted policy, and the preauthorization claim
+fingerprint. The Grant verification receipt then binds the Preauthorization claim receipt, Grant,
+parent authorization, plan, environment, trusted authority attestation, and exact verifier identity.
+
+Execution claim and completion are distinct immutable receipts. The claim receipt binds the Grant
+verification and Preauthorization claim receipts plus the exact operation and safe run-scoped execution
+artifact root. It never contains result or completion fields. The completion receipt binds the claim
+receipt to `<artifact-root>/execution.json`, `<artifact-root>/case-result-set.json`,
+`<artifact-root>/evidence-manifest.json`, and the completion time.
+
+The lineage index references all five receipts at fixed paths under:
+
+```text
+.testing/runs/<run-id>/authorization-lineage/
+```
+
+Receipt artifacts are persisted as canonical JSON. Index validation recomputes each receipt's canonical
+JSON SHA-256 and requires its immutable ref, digest, value, and complete native source bindings. It
+validates every receipt and all cross-receipt links. Every ref must resolve to the same run root;
+cross-run, cross-repository, cross-plan, cross-environment, and cross-Grant substitutions fail closed
+even if an attacker can reserialize the outer receipt. The chain also requires one continuous Host
+authority, policy revision, Plan, and ready Environment Receipt from Preauthorization through Grant
+and execution, plus monotonically ordered claim, verification, execution, completion, and index
+timestamps.
+
+## Host integration
+
+The trusted Host must produce these receipts only after the corresponding real verifier or atomic
+claim succeeds and persist them immutably. A fixture verifier may exercise the contract, but it is not
+a production trust root. Loss of an exported receipt may be repaired only as an idempotent projection
+of the same authenticated durable state; a receipt must never be imported to recreate a claim.
+
+The durable generic Host reference implementation projects all five receipts at the Profile claim,
+Preauthorization claim, Grant verification, execution claim, and completion effect points. It writes
+canonical JSON without a trailing newline so the persisted byte digest is the receipt canonical
+digest, then validates the complete lineage index through this contract. Restart paths project the
+same bytes from authenticated durable state and reject an existing Grant that cannot be reconciled to
+its earlier claim. Raw durable handles never leave the Host.
+
+Routine human approval is not a requirement of this lineage. A trusted Host may make Profile and
+Preauthorization decisions through deterministic machine policy. That automation does not collapse
+the distinct single-use claims, turn audit receipts into capabilities, or grant publication,
+promotion, regression, or gating authority.
+
+Authorization lineage also does not replace target isolation admission. Before a target effect, the
+runtime independently requires the exact `testing-host.target-execution-boundary.v1` repository
+binding documented in `contracts/target-execution-boundary.v1.md`. Compatibility, machine policy
+admission, Preauthorization, and a valid Grant cannot authorize an unknown repository when that
+boundary is absent or mismatched.
+
+Existing Project Profile, Grant request/result, structured execution request-v3, and summary-v1
+contracts remain unchanged. Production consumers requiring authorization lineage must use a future
+explicit request/result version or a separate lineage index; adding receipt fields to strict v1 payloads
+is not backward compatible.
+
+Diagnostic counters such as `claim_count = 1` or `grant_write_count = 1` do not substitute for this
+receipt chain.

contracts/target-execution-boundary.v1.md

@@ -0,0 +1,56 @@
+# Target Execution Boundary v1
+
+`testing-host.target-execution-boundary.v1` is a Host-owned admission contract for every command or
+HTTP effect that can reach a target repository or its running application. It is not emitted by the
+target repository, the implementation worker, PQL, or a run-scoped artifact producer.
+
+The current package accepts exactly one mode:
+
+```json
+{
+  "schema": "testing-host.target-execution-boundary.v1",
+  "mode": "trusted-fixture-exact",
+  "target_class": "host-owned-exact-trusted-fixture",
+  "repository": {
+    "url": "https://example.invalid/testing/fixture.git",
+    "commit_sha": "0123456789012345678901234567890123456789"
+  },
+  "authority": {
+    "kind": "host-policy",
+    "ref": "fixtures/reviewed-fixture-boundary"
+  },
+  "policy_revision": "reviewed-fixture-policy-v1",
+  "human_approval_required": false,
+  "authorization_capability": false,
+  "execution_authorized": false,
+  "promotion_authorized": false
+}
+```
+
+The repository URL must be canonical, credential-free HTTPS and the commit must be a full lowercase
+40-character SHA. The Host runtime config must live under `.testing/host/**`, while the operation
+artifact root must live under `.testing/runs/**`; the two namespaces cannot overlap. Environment
+Factory validates the boundary before checkout, target commands, readiness, and target cleanup.
+Structured Execution independently validates it before issuing a CLI effect receipt, consuming that
+receipt, or sending a target HTTP request. The Generic Host persists the same exact binding in its
+durable Host config.
+
+`trusted-fixture-exact` means that the Host operator has reviewed and admitted that exact immutable
+fixture. It must not be inferred from repository contents, a PQL compatibility result, an asset
+admission, an execution preauthorization, or a Grant. A URL or commit mismatch fails closed with
+`HOST_RUNTIME_ISOLATION_REQUIRED`.
+
+No other execution-boundary mode is currently accepted. In particular, a boolean such as
+`isolated=true` is not evidence of isolation. A future untrusted-repository mode requires a separate,
+verifiable Host-owned receipt from an OS identity, container, VM, or equivalent filesystem boundary
+that prevents target code from reading or replacing Host credentials.
+
+The private HOME lease, disabled Git credential helpers/hooks/fsmonitor, and removed GitHub and SSH
+environment variables are defense-in-depth controls for an admitted fixture. They are not an
+operating-system sandbox and do not make arbitrary code under the Host UID safe.
+
+The trusted Host may set `FKST_WORKER_RUNTIME_ROOT` to keep worker HOME allocation separate from the
+FKST framework's own `FKST_RUNTIME_ROOT`. The worker root must be a Host-owned, non-symlink private
+directory with no group or other permission bits. Existing Hosts that omit it use `FKST_RUNTIME_ROOT`
+for compatibility, but the same private-directory checks still apply and fail closed. Neither root,
+the object-bound allocation/cleanup broker paths, nor their digests are inherited by target workers.