# Intake records ## MASON-IN-0001 — Grandfather the legacy MASON-0001 identifier scheme ```yaml id: MASON-IN-0001 kind: intake title: Grandfather the legacy MASON-0001 identifier scheme lane: green status: closed outcome: absorbed origin: residual origin_ref: MASON-WP-0002 priority: low owner: ops-mason description: The finished bootstrap workplan uses legacy MASON-0001 and noncanonical MASON-0001-Txx identifiers, including a duplicate T01. Fleet canon says existing identifiers are never renamed and legacy schemes must be grandfathered. Coordinate with the Custodian canon steward and Repo Manager to add the exact legacy scheme mapping, then verify statehub consistency without rewriting registered UUIDs or historical source identity. notes: Custodian decision 3c487545-ee40-4049-89fa-34b41747a7eb grandfathered the exact MASON-0001 workplan and MASON-0001-TNN task schemes. Registered UUIDs remain unchanged, and the duplicate MASON-0001-T01 source blocks are indexed as one logical task while retaining both source locations as diagnostic provenance. Absorbed by that decision and the CUST-WP-0063 canon/validator update. created: '2026-08-22T09:33:08.629717Z' updated: '2026-08-22T21:19:02Z' state_hub_intake_id: "01a028d1-c4af-7a06-adb5-c90399721872" ``` ## MASON-IN-0002 — Declaration requested: state this repository's layer in INTENT.md (security layer model §11) ```yaml id: MASON-IN-0002 kind: intake title: 'Declaration requested: state this repository''s layer in INTENT.md (security layer model §11)' status: closed outcome: absorbed origin: cross-repo origin_ref: net-kingdom security-layer-model_v0.4 §11 priority: low owner: ops-mason requested_by: gate-house proposed_layer: Staff description: 'A conformance sweep on 2026-08-28 found this repository has no layer declaration of its own. It carries a layering review note gate-house wrote into the top of its INTENT.md on 2026-08-24, and that note names a layer — but the words are gate-house''s, sitting above a line admitting the body is unadapted. Section 11 has since been amended to say so explicitly: a layer stated about a repository by another repository is not a declaration; only the repository''s own file, in its own voice, conforms. Seven of fifteen estate-authored repositories have declared; this is one of the eight that have not. REQUESTED: state the layer in INTENT.md in your own voice, or contest it. PROPOSED LAYER: Staff. Builds and tears down access routes, credentials, and perimeters. Two things to state in your words: the Staff binding rule (you act through Engine APIs, never directly against Tooling — a grep of your own source is the check, as ops-warden did and found one), and the demarcation you are half of: ops-mason and ops-warden own access lanes, access-engine owns access rules. Contesting is a real option and costs nothing — the three repositories that reviewed this model each returned a correction, two of which changed the standard. If the proposed layer is wrong for what this repository actually does, that is more useful to us than a label added to close a checkbox. Standard: net-kingdom/canon/standards/security-layer-model_v0.4.md.' created: '2026-08-28T21:03:29.920563Z' updated: '2026-09-28T09:54:34.065401Z' notes: >- Closed against the repository-authored Staff / pep-shaped declaration in INTENT.md, dated 2026-09-21. That declaration names access-engine as the authorization decision point and explicitly records direct Tooling contacts and the founder-accepted plan-approval exception. The declaration request is fulfilled; the accepted conformance gaps and their 2026-12-21 review remain declared and are not marked conformant by this intake closure. state_hub_intake_id: "01a06e68-575c-714f-b572-79bcd739c3a0" ``` ## MASON-IN-0003 — Construct the fluid-telegram adapter read lane ```yaml id: MASON-IN-0003 kind: intake title: Construct the fluid-telegram adapter read lane status: open origin: cross-repo origin_ref: FT-WP-0002-T06 priority: high owner: ops-mason requested_by: ops-warden description: Design and construct a runtime identity for the fluid-telegram adapter after its deployment identity is declared. The lane may read only the campaign's bot-token and redaction-salt entries. It must be denied operator-app and operator-session, must not reuse the attended provisioner OIDC role, and must pass positive plus sibling-workload/campaign and operator-credential negative checks before ops-warden activation. Demand message 287cf897-7f47-4bcc-87d6-085f43d5f03e; parent construction workplan MASON-WP-0005. created: '2026-09-04T21:55:00+02:00' updated: '2026-09-04T21:55:00+02:00' state_hub_intake_id: "01a06e68-8c29-7230-b0dc-88f1e374afa4" ``` 2026-10-09: the parent operator plan is approved (MASON-WP-0005-T03), so this lane can be designed once the adapter's deployment identity is known. Nothing in fluid-telegram declares one yet (no manifests; FT-WP-0002-T06 delivered only `internal/adaptercfg`, whose `LoadToken` reads `bot-token` alone). Asked fluid-telegram (message `6d06bd9d`): where the adapter runs (Kubernetes SA with ESO, or a host AppRole), whether it needs `redaction-salt` as well as `bot-token`, and per-campaign or shared. ## MASON-IN-0004 — Close the policy-plus-AppRole escalation path in ops-mason-build ```yaml id: MASON-IN-0004 kind: intake title: Close the policy-plus-AppRole escalation path in ops-mason-build status: closed outcome: resolved origin: review origin_ref: inbound-library ILIB-WP-0003 (finding raised 2026-10-05 while preparing the first grant) priority: high owner: ops-mason requested_by: founder description: >- policies/ops-mason-build.hcl says OpenBao, not convention, enforces "ops-mason never reads a secret value". The explicit denies on platform/, operators/ and secret/ data hold only for tokens that carry ops-mason-build. The same grant can also do the following: (1) create or update any ACL policy except its own (sys/policies/acl/*); (2) create or update any AppRole role and read or write anything beneath it (auth/approle/role/*), which includes reading role-id and minting secret-id; (3) do the same for Kubernetes auth roles. A grant holder could therefore write a policy granting read on platform/data/*, bind it to a new AppRole, read that role's role-id, mint a secret-id and log in. The resulting token does not carry ops-mason-build, so none of its denies apply. Kubernetes roles allow the same path for anyone holding a service-account JWT. This was confirmed by reading the policy text. It was not exercised. The builder legitimately needs to write policies and mint secret-ids to deliver AppRole lanes, as it did for inbound-library-imap-approle on 2026-10-05. A path-level deny on secret-id would therefore break every build. Parameter constraints such as allowed_parameters with token_policies=workload-kv-read-* narrow the role binding but not policy content, because a policy with a conforming name can still grant platform/data/*. options: >- (a) Separation of duties: ops-mason drafts policy HCL in the plan, and the founder applies the policy write in an attended operator session. The grant loses sys/policies/acl/* create/update and keeps role binding and delivery, restricted by allowed_parameters to the policy names the plan approved. (b) Detective control: after every build, re-read the written policy and role and compare them to the approved build_spec (policy text derived from kv_path and capabilities). Alert from the OpenBao audit log on any sys/policies/acl write or role secret-id mint by a claude-* display_name that has no matching build-log record. (c) Two grants: a read-only survey grant (survey, metadata, capabilities), and a build grant minted only after plan approval and scoped by allowed_parameters to that plan's exact policy and role names. Bao policies cannot template on plan content, so this means minting a per-plan policy at grant time, itself an operator act. These can be combined, for example (b) now and (a) or (c) as the structural fix. This is a decision for the founder. Do not widen or loosen ops-mason-build while it is open. notes: >- A survey needs only (c)'s read-only grant. Today MASON-WP-0008 plan-survey runs under the full build grant, so separating them also reduces what a survey session can do. resolution: >- Founder decision (Bernd Worsch, 2026-10-07, given in the key-cape session): (c)+(a), a read-only grant only. ops-mason gets the read-only ops-mason-survey policy (policies/ops-mason-survey.hcl: read/list on mounts, auth methods, policies, auth role definitions and KV metadata; capability queries; lookup-self and revoke-self; explicit denies on */data/*, its own policy, and AppRole role-id / secret-id / secret-id-accessor / custom-secret-id). No policy writes, no auth-role writes, no secret-id minting, no token creation. Those acts go through the founder-attended railiance-platform delegated applier (scripts/credential-change.py applier-apply under warden access openbao-platform-admin-login --exec), as for CCR-2026-0033/0034 on 2026-10-07. ops-mason-build moved to policies/retired/ with a do-not-install header; it was not present in OpenBao at the time. bao-session.sh, plan-survey.py, custody-inventory.py, tests, AGENTS.md, INTENT.md and docs/construction-plan-format.md switched to ops-mason-survey. Installing the policy is a founder act (AGENTS.md, "Installing the survey policy"). Commit: 6b17727. updated: '2026-10-07T00:00:00Z' installed: >- 2026-10-07 by the founder through warden access openbao-platform-admin-login. The stored policy's sha256 c2dc066d76b1b9f0... matches policies/ops-mason-survey.hcl byte for byte. Correction: the note that ops-mason-build is not installed was wrong. The grant script's "does not exist" message came from an expired operator session. MASON-WP-0009-T04 found ops-mason-build still installed and bound to no role. The founder deleted it on 2026-10-07 through the warden platform-admin login. A follow-up read shows ops-mason-build absent and ops-mason-survey present. state_hub_intake_id: "01a11118-1f35-7ad5-ad51-65dd785c932f" ```