the-custodian/docs/changes/netkingdom-target-2026-10-16/mason-browser

Mason browser-case source compatibility

Owner work: MASON-WP-0010-T03, first consumer NK-WP-0048-T06 / TSA-04. Isolated checkout /tmp/netkingdom-mason-browser-20261016, source base e4761b843cd881a672cbb33a5b451de31a61d730; canonical owner dirt preserved.

The actual Python APIs already accept an explicit types_root and can generate the sixth consumer role. The shipped CLI did not expose that argument. The patch passes --types-root through plan, build and structure-request, retaining NetKingdom's exact-version loader, default 1.1 selection and current admission. No new descriptor schema or structure protocol was introduced.

forgejo-1.2-draft-plan.md and forgejo-1.2-source-render.json are actual source projections of the acknowledged 1.2 type and its proposed Forgejo example. They have six objects and the dedicated consumer ESO role in namespace forgejo. They are not a reviewed plan, build bundle, structural Request or native receipt. The actual 1.2 case has no acceptance; this worker did not fabricate one to make build/request preparation succeed. The legacy 1.1 bundle remains historical, including its known incorrect consumer workload target. The current generator already fixes that target; reproducing the historical file as new evidence would be incorrect.

Validation: 50 passed (six new actual-source checks plus 44 existing plan, build and structure tests), git diff --check passes. Ruff was unavailable. New checks cover actual six-object draft rendering; default-root version refusal; ordinary unimplemented refusal; proposed-case build refusal before any output; historical bundle refusal under 1.2; and malformed consumer namespace refusal by the actual NetKingdom validator. No live calls, credentials or effects occurred.

implementation.patch changes only the Mason CLI, tests, existing owner document and existing workplan. Apply after review to ops-mason, rerun the scoped command in validation.json, then run owner State Hub consistency through the coordinator. No task status or acceptance promotion is included. No duplicate workplan exists.

Contracts still required from the existing owners

• NetKingdom and the actual case acceptors: the exact accepted 1.2 case and reviewed current plan before Mason builds a six-object bundle/Request; do not carry historical 1.1 approval forward or label an offline plan reviewed.
• Platform + Mason: authenticate ops-mason.case-structure-request.v1 observations for each exact policy, role and fixed layout; distinguish created from matched preexisting objects; reconcile CCR41/CCR42 source bindings and owner admission. StatusBinding needs independent owner authentication binding the accepted and materialized raw case hashes. The injected test verifier supplies no authority.
• KeyCape + NetKingdom: accepted exact adapter source/descriptor for groups, client registration and environment/registry checks, with current case/type pins, native UID/resource-version preconditions, attributed observations and created-only undo. No descriptor or owner assent is authored here.
• Platform: broker mint descriptor with exact actor/lane/source/catalog/attempt pins and separate broker-grant/parent-session revocation evidence; metadata-only delivery/status/undo adapter with created-object ownership and token revocation or independently proved expiry. Already-present outcomes require reconciliation.
• Forge/consumer owner (railiance-apps): admitted consumer ESO binding/deployment and Forgejo configuration adapter or authenticated receipt-only step; independent successful sign-in, denied-group, revocation and rollback observations.
• NetKingdom + Warden: actual owner-accepted descriptors in a reviewed type revision and authenticated admission of original receipts. A source checksum, unsigned journal row or generated inventory is not native acceptance.

The first case remains unmaterialized/unaccepted for native completion. Remaining work stays in MASON-WP-0010-T03, NK-WP-0048-T06 and their existing owner records.