ops-mason/SCOPE.md

SCOPE

One-liner

Builder of NetKingdom security infrastructure — creates, changes, maintains, and tears down OpenBao AppRoles, policies, and KV secret paths so ops-warden always has something real to route to.

Core Idea

Four-phase process: (1) construction plan — respect/extend/compact existing structure before proposing new; (2) review/optimize against what already exists; (3) executive summary — the one mandatory human decision gate, in plain terms; (4) build, only after approval.

In Scope

• Construction plans for new/changed/retired OpenBao AppRoles, policies, KV secret path structure (never values)
• Consistency review — reuse over duplication, compaction over sprawl
• The executive-summary format that makes a plan decidable at a glance
• Proposing pointer-only entries (warden_executes: false, no authored steps) in ops-warden's routing catalog for what it builds — a normal git contribution to that repo, not a live API
• Its own audit trail of what it built, under which approved plan

Out of Scope

• Deciding whether access should exist — that's architecture/founder, ops-mason builds what's already decided
• Runtime authorization decisions — access-engine
• Identity/MFA — key-cape/Keycloak
• Routing consumers to lanes once built — ops-warden
• SSH certificate issuance — ops-warden
• OpenBao cluster init/unseal, platform deploy — railiance-platform
• Touching secret values at all, even transiently — delivered via ops-warden's existing paste_once_provision desk instead

Current State

The four-phase construction process, OpenBao AppRole/Kubernetes-auth builders, metadata inventory, and guarded Kubernetes-plane CLI are implemented and tested. Construction plans and build evidence live in plans/ and docs/evidence/.

OpenBao builds require an approved plan whose machine-readable specification and approved digest match the supplied execution inputs. Existing policies are content-pinned before reuse. AppRole credentials are delivered through private, exclusive files; the builders do not read downstream KV values. See docs/construction-plan-format.md for review and execution requirements.

Kubernetes apply enforces pinned readiness tiers, the explicit whitehat placement, the dated policy-nexus transition, and recorded emergency activation. See docs/kubernetes-plane.md.

The layer declaration is Staff, with PEP-shaped behavior, in INTENT.md. The founder-approved plan-approval exception and direct-contact gaps remain explicitly declared; this is not a claim of full layer-model conformance.

Remaining work is held in existing blocked workplans: credential descriptions (MASON-WP-0004), the attended Telegram credential lane (MASON-WP-0005), and the 2026-12-21 readiness/approval review (MASON-WP-0006-T06). WORK-RECORDS.md is the generated index; workplan files remain the source of task status.

Getting Oriented

• Start with: INTENT.md
• Agent instructions: AGENTS.md
• Workplans: workplans/