INTENT §7/§8 + WARDEN-WP-0029: policy front door, build-phase posture, founder surface

Founder directive 2026-07-18: agents ask ops-warden what a credential
need requires; the founder is escalated to only for policy-required
decisions/identity acts, preferably via a local web interaction surface
— never tasked with raw mechanics (UI clicks, /tmp file drops).
Organization posture 'build' becomes declared configuration. Workplan:
warden plan front door, posture declaration, warden desk, file-drop
retirement, catalog freshness + agent guidance.

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

INTENT.md

@@ -170,6 +170,37 @@ Every ops-warden action appends metadata-only audit events; `warden activity`
 answers *what happened recently* in one command. Compliance checks (scorecard) make
 cert-side policy violations visible before they become incidents.
 
+### 7. The founder is escalated to, never tasked with mechanics
+
+*(added 2026-07-18, founder directive — see WARDEN-WP-0029)*
+
+Workers and agents ask **ops-warden** what a credential need requires — never
+the founder directly. ops-warden answers three questions, in policy terms:
+
+1. Can this be done autonomously under current policy and posture? → do it /
+   route it, unattended.
+2. Does policy require a founder *decision or identity act* (OIDC login,
+   Red-lane approval)? → escalate exactly that act, nothing more.
+3. Is the need unroutable? → name the missing lane and propose it (CCR),
+   instead of improvising file drops or UI instructions.
+
+Raw mechanics — "paste this PAT into /tmp", "click through the forgejo admin
+UI" — are **anti-patterns**: they leak credentials into CLI history and file
+artefacts and burn founder attention on work a lane should do. When founder
+interaction *is* required, prefer a purpose-built interaction surface (local
+web approval page rendering the exact action) over CLI/file handoffs.
+
+### 8. Posture-aware: the organization is in build phase
+
+Policy answers depend on lifecycle posture. The organization currently runs in
+**build phase**: one founder-operator, pre-revenue, velocity prioritized —
+pragmatic provisioning (workstation OIDC, per-repo deploy keys, advisory
+policy gates) is deliberately acceptable where audit and custody invariants
+hold (values only in OpenBao/process env; metadata-only trails). ops-warden
+must know the current posture, state it in its answers, and tighten defaults
+when the posture graduates (first customer data, first non-founder operator,
+production tier). Posture is declared configuration, not tribal knowledge.
+
 ---
 
 ## Credential flow (target mental model)

workplans/WARDEN-WP-0029-policy-front-door-and-founder-surface.md

@@ -0,0 +1,138 @@
+---
+id: WARDEN-WP-0029
+type: workplan
+title: "Policy front door: posture-aware access planning + founder interaction surface"
+domain: infotech
+repo: ops-warden
+status: active
+owner: codex
+topic_slug: custodian
+planning_priority: high
+planning_order: 29
+created: "2026-07-18"
+---
+
+# WARDEN-WP-0029 — Policy front door + founder interaction surface
+
+## Origin
+
+Founder directive 2026-07-18 (binky-control cutover prep): agents proposed
+raw credential mechanics to the founder ("attach the deploy key in the
+forgejo UI", "save the PAT to /tmp/...") although a catalogued lane
+(`forgejo-admin-api-token`, WARDEN-WP-0025) already covered the need — the
+installed CLI's catalog was stale, and nothing forced the ask-warden-first
+step. Directive: **ops-warden is the service to ask what can and needs to be
+done** per NetKingdom policy; the founder is bothered only when policy makes
+it absolutely necessary, and then preferably via a purpose-built interaction
+surface, not CLI/file handoffs. The organization is in **build phase** and
+ops-warden must know that posture. INTENT.md principles 7 and 8 (added with
+this workplan) capture the direction.
+
+## Goal
+
+1. `warden plan "<need>"` — a policy decision front door: given a need, answer
+   *autonomous / founder-act-required / unroutable*, with the exact commands
+   or the exact founder act, posture-stated.
+2. Declared **organization posture** (`build`) that answers and scorecards
+   reference.
+3. A **founder interaction surface**: local web page for the rare founder
+   acts (approve, OIDC-login prompt, paste-once secret capture straight into
+   OpenBao) — no values through CLI history or files.
+4. Catalog freshness + agent guidance so ask-warden-first is the enforced
+   default.
+
+## Tasks
+
+### T01 — `warden plan` decision front door
+
+```task
+id: WARDEN-WP-0029-T01
+status: todo
+priority: high
+```
+
+New command: `warden plan "<need>" [--actor agt-...] [--domain ...]`.
+Resolves the routing catalog + posture + policy gates and returns a typed
+verdict: `autonomous` (with the exec-capable command sequence),
+`founder_required` (with the minimal founder act, e.g. "OIDC login role X" or
+"Red-lane approval Y"), or `unroutable` (with a CCR proposal stub). JSON
+output for agents. Every plan call audited (metadata only).
+
+### T02 — Declared organization posture (build phase)
+
+```task
+id: WARDEN-WP-0029-T02
+status: todo
+priority: high
+```
+
+Add `organization_posture: build` to the posture/registry configuration
+(alongside env posture dev/test/prod and workload maturity M0–M3), with the
+build-phase policy relaxations spelled out (workstation OIDC acceptable,
+per-repo deploy keys, advisory flex-auth) and the graduation triggers (first
+customer data, first non-founder operator, prod tier). `warden plan` and
+scorecard must state the posture in their output.
+
+### T03 — Founder interaction surface (local web approval page)
+
+```task
+id: WARDEN-WP-0029-T03
+status: todo
+priority: medium
+```
+
+`warden desk` (working name): serves a localhost, short-lived page when a
+plan needs a founder act — renders the exact action in plain language
+(approve/deny, launch OIDC login, or paste-once secret capture that writes
+straight to the OpenBao path and never echoes). No values in terminal
+scrollback, shell history, or files. Metadata-only audit per interaction.
+Build-phase scope: localhost only, no auth beyond OS session; hardening
+graduates with posture.
+
+### T04 — Retire file-drop patterns from playbooks
+
+```task
+id: WARDEN-WP-0029-T04
+status: todo
+priority: medium
+```
+
+Sweep wiki/playbooks (starting with
+`forgejo-admin-api-token.md` `/tmp/forgejo-tegwick-api-token` steady-state
+remnants) and replace file drops with `warden access --exec` / `--fetch`
+lanes or T03 paste-once capture. Update the two live consumers:
+railiance-platform `forgejo_package_prune` docs and binky-control cutover
+runbook.
+
+### T05 — Catalog freshness + agent guidance
+
+```task
+id: WARDEN-WP-0029-T05
+status: todo
+priority: medium
+```
+
+The stale-CLI failure mode: `warden` resolved an old catalog and hid an
+existing lane. Add a catalog version/freshness check (warn when installed
+catalog is older than repo/registry head; `warden route list` shows catalog
+date) and update AGENTS/CLAUDE guidance in ops-warden + consuming repos:
+agents must run `warden plan` before ever drafting a founder credential
+step.
+
+## Acceptance
+
+- `warden plan "forgejo deploy key for binky-control"` returns `autonomous`
+  with the admin-lane command sequence; `warden plan` for a new tenant
+  secret returns `founder_required` with exactly one founder act.
+- Posture `build` visible in plan output and scorecard.
+- One real founder act completed through the web surface with zero secret
+  values in CLI/files.
+- No playbook instructs a founder file drop.
+
+## See also
+
+- INTENT.md §7 (founder escalated, never tasked) and §8 (build-phase posture)
+- WARDEN-WP-0025 (forgejo admin token lane), WARDEN-WP-0026/0027 (disclosure
+  hygiene, governance lockdown)
+- binky-control DEC-2026-003 (first consumer: cutover without founder
+  mechanics)