133 lines
11 KiB
Markdown
133 lines
11 KiB
Markdown
# 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, FLEX-WP-0024 | Producer signing, strict consumer verification and fixed-verifier packaging source integrated; actual local serve-to-consumer proof passed | Independently admit package/keys/policy and verify native rollout |
|
||
| TSA-02–03 | Platform / Secrets / Approval; RPF-WP-0035-T12, SECRETS-WP-0013, APPROVAL-WP-0002/0004 | Strict handoff and durable consume/confirm/effect seam integrated; actual local source servers and disposable OpenBao path passed | Exact effect baseline/readback and recovery acceptance, then governed native admission |
|
||
| TSA-04 | NetKingdom / Mason / Warden / KeyCape; NK-WP-0048 | Browser evidence checker, Warden pinned metadata validation and Mason versioned source selection published | Admitted machine descriptors, real owner receipts and consumer acceptance |
|
||
| 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 | Workload-only credential delivery published; disposable bwrap proof reproduced; actual assignment and runner proof open | Admitted corrected runtime, combined rein acceptance and actual assignment migration |
|
||
| 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/` |
|
||
| `/root/warden_browser` | ops-warden | Exact producer validation on browser admission, WARDEN-WP-0044-T03 | `docs/changes/netkingdom-target-2026-10-16/warden-browser/` |
|
||
| `/root/agent_isolation` | glas-harness | Scope credential delivery to actual workloads, GLAS-WP-0012 | `docs/changes/netkingdom-target-2026-10-16/agent-isolation/` |
|
||
| `/root/approval_reference` | approval-engine | Atomic authenticated consuming identity and act/PDP evidence, APPROVAL-WP-0004 | `docs/changes/netkingdom-target-2026-10-16/approval-reference/` |
|
||
| `/root/access_verifier_review` | access-engine | Producer compatibility review and actual signing path, FLEX-WP-0024 | `docs/changes/netkingdom-target-2026-10-16/access-verifier-review/` |
|
||
| `/root/mason_browser` | ops-mason | Correct versioned browser type source resolution | `docs/changes/netkingdom-target-2026-10-16/mason-browser/` |
|
||
|
||
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.
|
||
|
||
The table records assignment history, not perpetual liveness. All eight owners
|
||
delivered initial source packages. Secrets and Access are preparing native
|
||
package/trust/caller admission. Platform is extending exact effect readback and
|
||
recovery evidence in disposable OpenBao. Approval delivered the focused source
|
||
closure and a separate exact-confirmation repair.
|
||
Exact revisions and publication caveats are in the
|
||
[source wave receipt](changes/netkingdom-target-2026-10-16/source-wave-status.json);
|
||
independent tests and retained failures are in the
|
||
[coordinator review](changes/netkingdom-target-2026-10-16/coordinator-source-review.json).
|
||
Raw patches and temporary reconstructions are workspace-local review artifacts;
|
||
the published owner commits are the durable source.
|
||
|
||
| Published owner source | Change | Independent verification |
|
||
| --- | --- | --- |
|
||
| NetKingdom `c31d21ba` | Browser evidence checking without native acceptance inference | 103 tests |
|
||
| Warden `95835208` | Exact pinned producer and parameter-schema validation | 102 tests |
|
||
| Glas `7357115c` | Credentials delivered only to explicit workloads | 141 tests and actual disposable bwrap denial/redaction/teardown |
|
||
| Platform `59d1441c`, `99fd21ee`, `d042d468` | Durable cleanup, disposable native adapter and immutable grant projection | Successive suites: 73, 83 and 122 tests; counts overlap |
|
||
| Secrets `c80a9441` | Strict producer-type signature verification with independent trust configuration | 125 focused tests and producer provenance check |
|
||
| Access `ec21518e` | Actual serving path signs before recording; inert chart configuration | Real local serve-to-Secrets verification; unsigned, tampered and unsafe key-file cases refused |
|
||
| Approval `477c6839` | Atomic consuming-service identity and bound act/PDP audit fields | 44 tests |
|
||
| Mason `57411f25` | Explicit versioned type-source selection in all CLI commands | 50 tests |
|
||
|
||
The subsequent published revisions are Secrets `ebca4f5` (fixed-verifier release
|
||
bundle) and `ff1a13d` (strict task handoff), Platform `e2b832b` (journaled
|
||
consume/confirm seam), and Approval `eece796` (canonical consumed-act comparison).
|
||
Normal owner publication and reconciliation succeeded; exact receipts retain
|
||
remaining historical warnings.
|
||
Independent combined Secrets verification passed 133 focused tests and seven
|
||
packaging tests. Platform passed all 130 tests, then eight affected tests passed
|
||
with the final Approval client; that client separately passed 36 tests.
|
||
|
||
Normal owner publication succeeded for every listed revision. Platform's scanner
|
||
ref race and Access's first State Hub timeout were retried successfully. Mason's
|
||
unrelated pre-existing workplan edits prevent an exact whole-repository hub
|
||
revision claim. Generated-only writeback refusals were retained without bypass.
|
||
Secrets' normal scanner initially flagged two public UUID identifiers; clearer
|
||
constant names preserved their values and passed the unchanged scanner.
|
||
|
||
These are bounded source/backend proofs. Synthetic approvals and grants do not
|
||
establish production consumption or isolation of this interactive assignment.
|
||
The actual service-pilot policy still denies runtime admission. The missing strict
|
||
Secrets handoff now binds the signed decision, approval, exact grant and caller;
|
||
Platform reserves durably, journals consumption and independently confirms it
|
||
before effects. Actual Access and Approval servers passed this path with explicit
|
||
synthetic identity/key/policy admission. Denied confirmation leaves uncertainty
|
||
and permits no native effect. Six successful native calls still do not establish
|
||
the complete expected-state readback; that remains the next Platform proof.
|
||
Both Secrets and Approval now compare the existing canonical native digest,
|
||
refusing Python's boolean/integer equality ambiguity. The original counterexample
|
||
and intermediate test failures remain recorded.
|
||
|
||
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.
|