tegwick ed518fb876 Tighten the ops-warden boundary after reviewing its actual repo

Found two things in ops-warden's own code/docs that sharpen the
boundary beyond what INTENT.md originally said:

1. registry/routing/catalog.yaml enforces a real "no-double-source
   rule": non-SSH entries are pointer-only (id/title/need_keywords/
   owner_repo/subsystem/wiki_ref/canon_ref/reviewed/status), never an
   authored steps/cert_command block -- that's reserved for
   warden_executes: true (ops-warden's own SSH lane). ops-mason's
   catalog contributions must follow the same rule: warden_executes:
   false always, status: draft until verified, and it's a normal git
   contribution to ops-warden's repo, not a live registration API.

2. ops-warden already ships a founder-facing "paste-once provision"
   desk (src/warden/desk.py's paste_once_provision act) that writes a
   secret VALUE into an EXISTING KV path via a localhost-only web form,
   never through a terminal/chat/audit log. It does not create
   AppRoles, policies, or paths -- that gap is exactly what ops-mason
   fills. Clean split: ops-mason builds structure only and never
   touches a secret value, even transiently; the founder delivers the
   actual credential through ops-warden's existing desk once the
   structure exists.

Updated INTENT.md/SCOPE.md/MASON-WP-0001 accordingly.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-07-27 00:44:37 +02:00

1.8 KiB

Raw Permalink Blame History

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 — flex-auth
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

Charter only (INTENT.md). MASON-WP-0001 scopes the four-phase pipeline and its first real exercise: the rein-openweights OpenBao AppRole that glas-harness/GLAS-WP-0002-T02 is blocked on. No code yet.

Getting Oriented

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

1.8 KiB Raw Permalink Blame History