docs(security): define NetKingdom target and implementation gates

docs/netkingdom-target-implementation.md

@@ -0,0 +1,76 @@
+# NetKingdom target implementation record
+
+Coordinator: CUST-WP-0080. Target: [security architecture](netkingdom-target-security-architecture.md).
+Started 16 October 2026 under the founder's explicit implementation and
+GPT-6.1-Sol medium subagent request. The full architecture remains the goal.
+
+## Work ownership and current status
+
+| Gate | Existing implementation owner | Current evidence state | Next deliverable |
+| --- | --- | --- | --- |
+| TSA-01 | Secrets Engine / Access Engine; SECRETS-WP-0014 | Source implementation in progress; independent signer admission and native rollout pending | Producer-compatible verifier on actual consumer paths; trust/rotation/negative fixtures |
+| TSA-02–03 | Platform / Secrets / Approval; RPF-WP-0035-T12, SECRETS-WP-0013, APPROVAL-WP-0002 | Source compiler/journal exists; mediated native execution incomplete | Durable cleanup independent of business outcome; reviewed exact execution integration |
+| TSA-04 | NetKingdom / Mason / Warden / KeyCape; NK-WP-0048 | Type versions acknowledged; native first-reference acceptance incomplete | Completion verification against real owner receipts and missing adapter integration |
+| TSA-05 | KeyCape / User / NetKingdom / Playwright; KEY-WP-0040, NK-WP-0050, CUST-WP-0080-T05 | Native human and agent journey gates open | Actual recovery and browser consumer acceptance |
+| TSA-06 | Glas / Sand-boxer / rein / Platform / Forge; CUST-WP-0073, GLAS-WP-0012 | Actual assignment isolation and complete runner authority proof open | Admitted runtime and effective-authority denial tests |
+| TSA-07–08 | Secrets / NetKingdom / Platform; NK-WP-0049 and existing lifecycle plans | Inventory, lifecycle and independent recovery incomplete | Metadata denominator, elimination candidates, scoped recovery and lifecycle receipts |
+| TSA-09 | Audit / emitting owners; Approval T04 and current Audit work | Delivered custody; current source admission/reconciliation incomplete | Source/effect/outbox/receiver readback for first protected operation |
+| TSA-10 | Forge / Repo Manager; FORGE-WP-0006, RMGR-WP-0021 | Broad receive coverage delivered; other paths and response incomplete | Coverage/reliability gaps and private response acceptance |
+| TSA-11 | Reuse / provider owners | 70/70 discovery verified 15 October; stale descriptive fields remain | Correct source metadata and repeat drift/hosted checks |
+| TSA-12 | Activity / Coordination / Custodian; CUST-WP-0079 | Schedule accepted but unassisted activation not proven; cadence source adoption underway | Actual activation and first independent observation |
+| TSA-13–14 | NetKingdom / provider owners | Accepted reusable integration and second installation pending | Shared adapter conformance and minimal locked profiles |
+| TSA-15 | Resource / telemetry / consumer owners; CUST-WP-0071 where applicable | Optimization baseline incomplete | Comparable latency, effort, resource and scanner measurements |
+| TSA-16 | Custodian / governance and owner records | Governing records exist; target-wide evidence reconciliation open | Requirement-by-requirement closure audit under CUST-WP-0080-T04 |
+
+Each entry summarizes an owner obligation; it does not copy or replace that
+owner's task list. The original [requirement ledger](evidence/2026-10-12-netkingdom-security/sec-dsm-requirement-ledger.json)
+and owner receipts retain their original scope and outcomes.
+
+## Delegated implementation wave
+
+The founder requested model `gpt-6.1-sol`, reasoning effort `medium`. The
+coordinator dispatched these concrete child assignments using that configuration:
+
+| Handle | Owner role | Source scope | Artifact directory |
+| --- | --- | --- | --- |
+| `/root/decision_auth` | secrets-engine | Signed decision enforcement, existing SECRETS-WP-0014 | `docs/changes/netkingdom-target-2026-10-16/decision-auth/` |
+| `/root/protected_execution` | railiance-platform | Task execution journal/cleanup, RPF-WP-0035-T12 | `docs/changes/netkingdom-target-2026-10-16/protected-execution/` |
+| `/root/browser_case` | net-kingdom | First browser case verification/integration, NK-WP-0048-T06 | `docs/changes/netkingdom-target-2026-10-16/browser-case/` |
+
+Each child reads the assigned owner's instructions and intent. Prepared changes
+use isolated temporary checkouts based on current owner source, with relevant
+pre-existing tracked changes retained. Exact patches, source hashes and tests
+support coordinator review before integration. A child reviews only its own
+owner role; independent cross-owner reviews require separate assignments.
+
+This wave authorizes source implementation and preparation under the user goal.
+It grants no runtime credential scope or automatic native acceptance. Required
+owner checkout filesystem approval is distinct from authority to change live
+trust or credentials. No agent inherits another assignment's autopilot grant.
+
+## Dependency and residual handling
+
+The current implementation demand selects necessary target dependencies for
+owner review and scoped promotion. APPROVAL-WP-0002's exact issuer/provenance,
+audit and served-PEP obligations are required; its residual label must be
+reconciled by its owner before implementation dispatch. This does not activate
+every residual security plan or the deferred exposure rotation.
+
+Cross-owner waits attach to the existing project driver where one exists, or a
+derived `cross_owner_wait` case benefiting CUST-WP-0080. The dispatched child
+handles establish current execution, not a separate fleet wake service. If a
+child is terminal, record its deliverables and dispatch the next reachable owner
+task; never report a stale handle as running.
+
+## Evidence and completion rules
+
+For each change record the original owner revision, pre-existing dirty-state
+digest, exact patch, focused tests, independent review, integrated revision,
+publication and native acceptance separately. Bind each native receipt to target,
+identity, scope, source/image/config revision, expected result, negative cases,
+cleanup and rollback. Preserve failures and unverified outcomes.
+
+The coordinator reviews evidence against every TSA gate and the named owner
+requirements. It may record partial source delivery without closing a native
+gate. Work continues until the target's complete exit condition holds. The first
+wave is implementation progress, not the completion boundary.

docs/netkingdom-target-security-architecture.md

@@ -0,0 +1,217 @@
+# NetKingdom target security architecture
+
+Version 1, 16 October 2026. Implementation coordinator: [CUST-WP-0080](../workplans/CUST-WP-0080-netkingdom-security-blueprint-and-gap-closure.md).
+
+NetKingdom will provide a small set of reusable, independently verified security
+workflows. Identity, access decisions, approvals, credential custody and audit
+retain their existing owners. Consumers share adapters and case templates instead
+of reproducing those interfaces or deploying every capability as a service.
+
+The founder requested implementation of this direction after the
+[architecture review](netkingdom-security-architecture-review.md). This is the
+target and its acceptance contract; the [implementation record](netkingdom-target-implementation.md)
+tracks delivery. Source, deployed behavior and accepted consumer outcomes remain
+separate states. Existing scoped authorizations, human custody requirements and
+explicit rotation deferrals continue to govern execution.
+
+## Scope and current evidence
+
+The target covers the review's 60 capability-owning repositories, 70 reusable
+boundaries and use cases U01–U14. The complete [inventory](assessments/netkingdom-2026-10-14/capability-inventory.md)
+remains the provider denominator. It does not require deploying all providers for
+every consumer. On 15 October, hosted discovery contained all 70 reviewed IDs
+exactly once; the local entries included 44 A2 CLI/source capabilities and six A0
+informational capabilities. Discovery establishment is delivered. Maintaining
+truthful limits, source revisions and consumer evidence remains ongoing work.
+
+The operational baseline remains integration stage: the signed-decision consumer,
+task-scoped protected effect, first reusable browser case, actual agent isolation,
+source reconciliation and independent root recovery retain acceptance gates.
+The [gap register](netkingdom-security-gaps.md) and owner files carry the detailed
+history. A missing assessment is an unknown, not evidence that a control is absent.
+
+## Authority and placement
+
+| Responsibility | Authoritative owner | Target placement and simplification |
+| --- | --- | --- |
+| Security meaning and conformance | security-canon, net-kingdom, gate-house, info-tech-canon | Versioned source contracts, offline validators and published policy references; no mandatory runtime hop for document interpretation. |
+| Authentication and assurance | key-cape; user-engine for account journeys | Existing identity stack and explicit relying-party adapters. Account, group and factor recovery must work end to end before considering an identity-provider replacement. |
+| Tenant and other facts | tenant-engine and the relevant fact owner | Use only policy-required facts with explicit provenance and freshness. Zone and maturity reference tools are not implicitly live claim services. |
+| Authorization | access-engine | One decision owner and contract, with independently admitted consumer pins. Shared deployment requires a measured isolation and availability case. |
+| Approval and presentation | approval-engine; informed-decision | One bound approval lifecycle, separate presentation; no approval inferred from a report, case type or scheduler. |
+| Credential lifecycle and custody | secrets-engine; railiance-platform/OpenBao | Native identity first, scoped short-lived credentials next, managed static credentials only where necessary. Secrets Engine remains a CLI/workflow capability. |
+| Operational access and construction | ops-warden, ops-mason, ops-bridge | Reuse routing, case follow-through, reviewed structure and private transport; no general umbrella broker. |
+| Independent evidence | audit-core | Durable custody and admitted reconciliation; original owner receipts stay authoritative. State Hub indexes references rather than becoming security custody. |
+| Agent execution | glas-harness, sand-boxer, the selected rein | An admitted task identity and enforced profile; tools and inherited credentials count as effective authority. |
+| Deployment and recovery | existing Railiance, rail, reef and rapp owners | Pinned packages, owner deployment paths, off-host recovery resources, measured headroom and declared rollback. |
+| Discovery and improvement | reuse-surface, repo-manager, kings-guard, maturity-engine, activity-core, coordination-engine | Derived discovery and observations feed deduplicated owner work. Scheduling and scores never create permissions. |
+
+## Consumer profiles
+
+### Application access
+
+An application authenticates the caller using its admitted issuer, verifies the
+required identity/tenant/assurance claims, obtains an Access Engine decision, and
+enforces the exact authorized resource/action. User or tenant lookup is included
+only when required by that application's policy. Cached facts need an explicit
+freshness and revocation contract. Policy-required unavailable or stale facts
+cannot become a permissive default.
+
+Identity token verification fixes accepted algorithms, issuer, audience, token
+type and lifetime. Decision verification independently authenticates the admitted
+PDP signer or channel and checks request, policy and validity bindings. A digest
+alone does not authenticate its producer. The current producer's signed envelope
+format remains authoritative; consumers must not invent another canonicalization.
+
+### Protected operation
+
+```mermaid
+flowchart TD
+    R[Exact action and execution readiness] --> H[Required human review]
+    H --> A[Bound Approval Engine claim]
+    A --> D[Authenticated Access Engine decision]
+    D --> V[Consumer validates identity scope digests and lifetime]
+    V --> C[Atomic approval consumption before effect]
+    C --> J[Durable operation admission]
+    J --> E[Owner mediated exact effect]
+    E --> Q[Verified outcome or retained uncertainty]
+    Q --> X[Scoped cleanup and credential revocation]
+    J --> O[Durable source evidence]
+    Q --> O
+    X --> O
+    O --> U[Audit Core custody and independent reconciliation]
+```
+
+The first implementation is the existing narrow metadata `execute-ccr` contract
+in SECRETS-WP-0013 and RPF-WP-0035-T12. The request binds initiating identity,
+tenant, action, target, payload/source digest, policy revision, approval binding
+and catalog fingerprint. Exact envelope field names and canonical bytes come
+from the owner contracts, not a second Custodian schema.
+
+Readiness is established before spending the approval. Consumption precedes the
+protected effect. Approval single-use does not imply exactly-once execution at
+OpenBao: the durable ledger and target-specific preconditions must preserve
+unknown outcomes, reject competing or changed requests, and reconcile actual
+state before any authorized retry. A lost response never justifies replay.
+
+Cleanup obligations are durable before resources are created. Business failure
+or uncertainty cannot erase cleanup duties. Cleanup is restricted to the
+operation's identified resources and cannot grant a new business effect. Recovery
+records retain the original outcome and any rescue. Credentials remain in the
+owner execution path; the requesting agent receives sanitized receipts.
+
+### Known browser case
+
+Finish `oidc-browser-relying-party` with Forgejo under NK-WP-0048 before adding
+more type families. The selected type version, parameters, provider revisions,
+owner adapter receipts and rendered plan are pinned. Native structure,
+contained mint/delivery, successful sign-in, denied groups, revocation and
+rollback are verified independently. Acknowledged, implemented, materialized and
+live are distinct states. A case renderer always remains plan-only.
+
+After this case passes, a second consumer proves reuse of its adapters and
+contracts. Rapp Playwright's human/agent identity and connectivity remain an
+explicit consumer acceptance obligation under CUST-WP-0080-T05 and NK-WP-0050;
+a deployed browser package alone does not satisfy it.
+
+### Agent and runner execution
+
+An admitted Glas/Sand-boxer/rein profile denies access to admin material through
+files, mounts, environment, subprocesses and available tool paths. Tasks use
+distinguishable scoped identities, bounded delegation, cancellation/expiry
+cleanup and no cross-task credential accumulation. The actual running assignment
+must pass; a sandbox fixture does not establish interactive-runtime isolation.
+
+CI writers, runner execution and deployment credentials have separate scopes.
+Repository-controlled workflows cannot disable the independent receive scanner
+or reach unrelated deployment credentials. Required checks, artifact provenance,
+per-job identities and import/mirror scanning need their own acceptance evidence.
+
+### Recovery and operations
+
+Inventory roots, ordinary credentials, copies and consumers using metadata.
+Each managed credential has owner, purpose, exact scope, issuer, delivery,
+consumers, expiry/rotation, revocation, recovery and an elimination condition.
+Replacement acceptance proves both successor adoption and predecessor refusal.
+The existing founder-deferred exposure rotation remains explicitly deferred.
+
+Recovery succeeds with the ordinary issuer/cluster unavailable, using independently
+reachable encrypted custody and recovery access. Prove restore integrity,
+consumer reconnect, audit continuity and return to ordinary custody. Set scenario
+RTO/RPO and measure actual results. Single-node/shared-control-plane risk remains
+the accepted build-mode exception until its stated production gate; the target
+does not silently impose an HA migration or waive that gate.
+
+## Shared implementation surfaces
+
+- Maintain the request/decision/approval verifier per supported language with
+  producer-owned golden vectors. Any vendored producer code is pinned, attributable
+  and checked for drift. Install/build behavior is part of adapter acceptance.
+- Use existing SecurityCase templates to generate owner-specific plans, negative
+  checks and rollback steps. Reuse accepted authority only within its exact scope;
+  changes to authority or approved executable revisions follow their existing gates.
+- Correlate approval, decision, admission, effect, cleanup and audit by stable
+  references. Preserve failed attempts. Store original evidence once and link it
+  from summary reports; independent audit custody is intentionally separate.
+- Provider source owns capability facts, owner workplans own task status, and
+  deployment receipts establish runtime state. Derived indexes report drift and
+  unknowns instead of introducing another manually maintained status source.
+- Use the existing coordination frame for explicitly adopted cadence consumers.
+  Source adoption currently selects `f=1h`, registered wait `2f`, effective
+  missing-heartbeat deadline `3f`. Verify runtime and receiver adoption. Credential
+  TTLs, approval validity, transport retries and worker leases remain separate.
+- Keep feedback proposal-only until the existing authorization path admits an
+  action. Activate the existing security-flow schedule and verify unassisted
+  operation; deduplicate findings by affected owner, control and evidence scope.
+
+## Acceptance contract
+
+These gates are cumulative and bounded to their named denominators. Completing
+source changes cannot mark a native gate achieved. A requirement with an accepted
+exception records its actual governing decision and exit trigger; new exceptions
+require that authority and cannot be authored to improve completion statistics.
+
+| ID | Target outcome | Required evidence and owner work |
+| --- | --- | --- |
+| TSA-01 | Every inventoried privileged PEP authenticates its decision | PEP denominator; admitted signer/channel; forged, altered, wrong-key/pin, unsigned/downgrade, expired and rotation refusals. Start SECRETS-WP-0014. |
+| TSA-02 | Exact approval produces one bounded protected operation | SECRETS-WP-0013/RPF-WP-0035-T12 native effect; Approval T01/T05 issuer/tenant provenance; wrong actor/tenant/body, expiry, replay and unavailable refusal. |
+| TSA-03 | Crashes preserve uncertainty and cleanup | Actual ledger restart/concurrency, consumed-before-effect failure, target reconciliation, scoped cleanup and revocation evidence; no blind replay. |
+| TSA-04 | First reusable browser case is accepted | NK-WP-0048 and named Mason/Warden/KeyCape adapters; independent native structure, sign-in/denial, delivery, revocation and rollback. |
+| TSA-05 | Human and browser consumers can use the delivered identity | KEY-WP-0040/U08 real-factor recovery; User Engine journey; NK-WP-0050 and CUST-WP-0080-T05 human/agent Playwright acceptance. |
+| TSA-06 | Actual agent and runner authority is bounded | CUST-WP-0073/GLAS-WP-0012 admitted runtime read-denial/tool-effect proof; Forge/Platform per-job credential and repository-workflow abuse tests. |
+| TSA-07 | Credential lifecycle is inventoried and simplified | Current owner/consumer denominator, unknown/orphan findings, native-identity elimination candidates; sampled replacement/adoption/old-refusal and deletion semantics. G04/G09/G12. |
+| TSA-08 | Recovery is independent and measured | NK-WP-0049 plus platform/root owners; isolated recovery with ordinary issuer unavailable, restore/reconnect/audit continuity and measured RTO/RPO. G08/G11. |
+| TSA-09 | Security effects have independently reconciled evidence | Admitted source/class inventory, atomic outbox, receiver readback, lag/duplicate/boundary accounting and missing-class findings. Approval/Audit/Tenant/Secrets owners. |
+| TSA-10 | Source and delivery controls cover declared entry paths | FORGE-WP-0006/RMGR-WP-0021: denominator, SSH/HTTP/UI/new repo/import/mirror coverage, required checks/provenance, private synthetic finding through resolution. |
+| TSA-11 | Discovery remains accurate | All reviewed IDs exactly once, owner/index parity, usable source links, current limits/version aliases, drift checks and package-family disposition. Reuse/Repo Manager/provider owners. |
+| TSA-12 | Improvement operates without repeated manual polling | CUST-WP-0079/Activity accepted schedule, unassisted firing, checkpoint and changed-state notifications; adopted cadence runtime/receiver receipts; owner change and native remeasurement. |
+| TSA-13 | Shared adapters reduce per-consumer implementation | Producer-format cross-language fixtures, two real consumers, version compatibility, denied-path parity, upgrades and rollback; no second PDP. |
+| TSA-14 | Minimal profiles are independently reusable | Version/provider lock, dependency and optional-provider declaration, provider adapters, second clean installation, complete positive/negative journeys and upgrade/recovery instructions. |
+| TSA-15 | Optimization improves measured operations | Baseline and repeat measurements of onboarding time/touches, p50/p95 decision/effect latency, scanner throughput/failure, resources/headroom and owner effort with unchanged control coverage. |
+| TSA-16 | Governance and exceptions remain truthful | Existing SEC-DSM ledger and close-down controls reconciled to exact evidence; real authority for changes, explicit residual promotions, preserved deferrals and no invented owner assent. |
+
+## Rollout and exit
+
+Start authenticated decisions and the bounded metadata operation, with audit
+acceptance included. Agent isolation is a parallel priority. Finish the existing
+browser case rather than opening a third reference journey. Inventory, recovery
+preparation, discovery corrections and source checks may proceed alongside these
+two integrations. Package accepted interfaces and extend consumer coverage next.
+
+Changes use owner repositories and their existing workplans. Scoped independent
+owner reviews precede required native activation. The standing build-mode rule
+already authorizes qualifying non-destructive changes with reviewed diff/dry-run,
+rollback, abort owner and receipts. Access/secret policy scope changes, destructive
+operations, new spend ceilings and public publication retain their explicit gates.
+Existing exact approvals are reused within scope, not requested again.
+
+Rollback either restores the previously admitted behavior within its accepted
+exception or leaves the affected operation unavailable. It never silently accepts
+an unsigned decision, widens scope or resurrects a revoked credential. Native
+failure remains evidence and prevents further promotion until resolved.
+
+The goal completes only when TSA-01 through TSA-16 have scope-matched acceptance
+evidence or an already applicable explicit governing exception, the second
+consumer/installation proves reuse, and no required work is left only in prose.
+Evidence review must inspect actual sources and outcomes; a green aggregate
+report or completed child agent is insufficient.

workplans/CUST-WP-0080-netkingdom-security-blueprint-and-gap-closure.md

@@ -1,14 +1,14 @@
 ---
 id: CUST-WP-0080
 type: workplan
-title: "NetKingdom security blueprint and SEC-DSM gap closure"
+title: "NetKingdom target security architecture and SEC-DSM implementation"
 domain: infotech
 repo: the-custodian
 status: active
 owner: codex
 topic_slug: custodian
 created: "2026-10-12"
-updated: "2026-10-14"
+updated: "2026-10-16"
 flavor: implementation
 depends_on: []
 state_hub_workstream_id: "dfadb19b-445e-59c6-bcd6-48e87b912c52"
@@ -19,6 +19,18 @@ implementation and native acceptance ownership. This plan adds the cross-cutting
 SEC-DSM assessment and tracks uncovered findings without duplicating their tasks.
 Explicitly deferred or residual work is not silently promoted.
 
+2026-10-16 founder continuation: document the optimized target architecture and
+drive implementation using GPT-6.1-Sol medium subagents. The normative target for
+this implementation effort is `docs/netkingdom-target-security-architecture.md`;
+`docs/netkingdom-target-implementation.md` links all sixteen acceptance gates to
+existing owner work. This extends the existing coordinator rather than creating
+a parallel security backlog. T03 retains source/lifecycle implementation, T05
+the browser consumer, and T04 native requirement closure. Existing scoped live
+authorizations and deferrals remain applicable. Necessary residual dependencies
+receive explicit owner-scoped promotion before implementation, never a blanket
+activation. The full target remains incomplete until every acceptance gate is
+proved at its stated scope.
+
 ## Review canon and map actual architecture
 
 ```task
@@ -610,3 +622,23 @@ protected executor/recovery-state integration, admitted identity/custody, exact
 current image/cluster and supervised live acceptance remain open. Receipt:
 `playwright-activation-preparation.json` in the October 13 evidence directory.
 No live credentials or deployments changed; this does not close consumer delivery.
+
+
+## Establish the target architecture and drive the restructuring
+
+```task
+id: CUST-WP-0080-T06
+status: progress
+priority: high
+```
+
+Founder implementation request, 2026-10-16. Document the optimized target and
+coordinate GPT-6.1-Sol medium agents against the existing owner work. Delivered
+`docs/netkingdom-target-security-architecture.md` with sixteen scope-specific
+acceptance gates and `docs/netkingdom-target-implementation.md` with ownership,
+dependency and evidence rules. First dispatched source work: Secrets Engine
+decision authentication, Platform durable cleanup, NetKingdom first-case
+compatibility. Exact handles and artifact locations are in the implementation
+record. Documentation link/ID checks pass. Implementation and native acceptance
+remain open; this task closes only with the target's exit condition and T04
+requirement audit, not with the first source wave.