BINKY-WP-0003-T02: OK audit template v1 (AWQ-001)

Company-agnostic flagship-offer template generalized from the Binky
dogfood run. audit-core assessed as home candidate — it owns audit event
logging, not company audits, so the template stays in binky-control.

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

AutopilotWorkQueue.md

@@ -5,13 +5,6 @@
 
 ## Queue
 
-```yaml
-id: AWQ-001
-title: "Generalize audits/OK-Audit-v0-binky.md into a customer-ready audit template v1"
-lane: green
-pulls_from: [OfferCatalog.md flagship dependencies]
-```
-
 ```yaml
 id: AWQ-002
 title: "Map self-billed Eigenentwicklung invoices to ecosystem capabilities as IP evidence"
@@ -51,18 +44,6 @@ lane: green
 pulls_from: [EcosystemMap.md cartography v0 caveat]
 ```
 
-```yaml
-id: AWQ-007
-title: "Onboard company email (bernd.worsch@binky-hedgehog.com) into Net Kingdom / OpenBao"
-lane: blue
-pulls_from: [audits/OK-Audit-v0-binky.md digital presence, identity-and-access capability]
-notes: "Store credentials in OpenBao; wire mailbox into agent event loop (email-connect
-  is the natural capability). Credential handover from founder is Red-lane — prepare
-  the vault path and integration plan first, then request the secret once. Goal:
-  real-world events (StB replies, Qonto notices) reach the control plane. Direct
-  dogfood of the net_kingdom + railiance pillars."
-```
-
 ```yaml
 id: AWQ-008
 title: "Design weekly paper-mail scan intake pipeline"
@@ -82,4 +63,12 @@ with a one-line outcome.
 
 ## Completed
 
-*(none yet)*
+- **AWQ-001** (2026-07-16, BINKY-WP-0003-T02): audit template v1 at
+  `templates/OK-Audit-Template-v1.md` — customer-ready, company-agnostic;
+  flagship-offer dependency cleared. Note: `audit-core` repo is event
+  logging, not the right home; template stays here for now.
+- **AWQ-007** (2026-07-16, BINKY-WP-0003-T01): company-email → OpenBao
+  integration prepared — vault path, secrets-engine catalog draft, and
+  email-connect wiring in `integrations/company-email-openbao.md`. Remaining
+  steps (provider facts, Red-lane credential handover) tracked in that
+  document's checklist.

OperatingRhythm.md

@@ -33,6 +33,31 @@ Rules:
    the top.
 4. Workplan files match hub state (fix-consistency covers drift).
 
+## Bridge scheduler (workstation cron)
+
+**Status: prepared, not installed** — installing a self-running agent loop is
+a founder action (the Claude Code permission layer rightly refuses to let an
+agent install its own persistence). Everything else is ready:
+`scripts/rhythm-session.sh` runs a headless, lane-restricted Claude Code
+session that does queue hygiene, writes the daily brief, and pulls one
+autopilot item (agent name `agt-rhythm-bridge`; flock guard, logs to
+`~/.cache/binky-control/rhythm/cron.log`).
+
+**Enable (founder, one line):**
+```bash
+( crontab -l; echo '23 8 * * 1-5 /home/worsch/binky-control/scripts/rhythm-session.sh # binky rhythm bridge' ) | crontab -
+```
+
+**Disable:** `crontab -e` and delete the `binky rhythm bridge` line.
+
+This is explicitly a **bridge**: once activity-core definitions (T05) and an
+llm-connect executor (T06 follow-up) are live, the cron line is removed and
+scheduling moves to the sanctioned coordination layer.
+
+Guardrails baked into the script: Green/Blue lane only, allowed tools limited
+to file edits + git add/commit, no push, no network, one-run-at-a-time lock,
+bounded "maintenance pass" prompt.
+
 ## Weekly review (founder, ~15 min)
 
 Read the newest brief + `SuccessMilestones.md`. One question: did anything

integrations/company-email-openbao.md

@@ -0,0 +1,119 @@
+# Company Email → Net Kingdom / OpenBao Integration Plan
+
+> Status: prepared v1 — 2026-07-16 (BINKY-WP-0003-T01, AWQ-007).
+> Goal: `bernd.worsch@binky-hedgehog.com` becomes an agent-readable event
+> source so StB replies, bank and authority notices reach the control plane.
+> **Credential handover is a single Red-lane founder step at the end** — no
+> agent solicits or stores the password before the vault lane exists.
+
+## Architecture (sanctioned path)
+
+Per `net-kingdom/docs/secrets-engine-security-infrastructure-boundary.md`:
+OpenBao owns custody/policy/audit; **secrets-engine** owns the workflow
+(catalog → decision → plan/apply → provisioning → exec-time delivery);
+**email-connect** is the consumer (read-only IMAP mailbox scan, MVP already
+supports `mailbox.protocol: imap` with credential *environment variable
+names* in config — values never in config files).
+
+```text
+founder (Red lane, once)
+   └─ provisions IMAP password into OpenBao via secrets-engine plan
+        └─ OpenBao kv: secret/prod/binky/company-email/imap
+             └─ secrets-engine exec --catalog binky-company-email-imap \
+                    -- python -m email_connect.cli scan-mailbox ...
+                  └─ scan reports / classified evidence → binky-control queues
+```
+
+## Draft secrets-engine catalog entry (non-secret)
+
+To be landed in `~/secrets-engine/catalog/binky-company-email-imap.yaml`
+after review (kept here as the reviewed source until then):
+
+```yaml
+id: binky-company-email-imap
+org: binky
+repo: binky-control
+stage: prod
+description: >-
+  IMAP credentials for the company mailbox bernd.worsch@binky-hedgehog.com.
+  Read-only mailbox scanning by email-connect so real-world events (StB
+  replies, bank/authority notices) reach the Binky control plane.
+
+mount: secret
+path: prod/binky/company-email/imap
+
+fields:
+  - imap_username
+  - imap_password
+
+consumers:
+  - name: email-connect-scanner
+    auth: approle
+    claim: "role:email-connect-scanner"
+    purpose: "read-only IMAP scan of the company mailbox"
+
+delivery_modes:
+  - exec-env        # secrets-engine exec injects IMAP_USERNAME/IMAP_PASSWORD
+
+approval:
+  model: decision   # State Hub decision + founder handover (Red lane)
+  notes: "Founder provisions the value once; agents never see or relay it."
+
+verification:
+  positive: "email-connect scan-mailbox completes a read-only folder scan"
+  negative: "no other consumer role can read prod/binky/* paths"
+
+rotation:
+  expectation: "on suspicion or provider change; founder-triggered"
+
+deactivation:
+  expectation: "disable AppRole + delete kv path if mailbox is migrated"
+
+audit:
+  evidence: "actor, path, timestamp, result — no secret value"
+```
+
+Non-secret connection facts still to confirm with the founder (Blue lane,
+not credentials): IMAP host/port for the binky-hedgehog.com mail provider,
+folder to scan (default INBOX).
+
+## email-connect consumer config (non-secret, draft)
+
+```yaml
+mailbox:
+  protocol: imap
+  host: <provider-imap-host>        # TODO: confirm provider
+  port: 993
+  folder: INBOX
+  username_env: IMAP_USERNAME
+  password_env: IMAP_PASSWORD
+```
+
+Scan output (CSV evidence reports) initially lands in this repo under
+`mailmeta/` (metadata only — no message bodies in git); triage routes items
+into DecisionQueue / OfficeHourQueue / RiskRegister, receipts toward DUO
+Belegablage (shared triage step with paper mail, AWQ-008).
+
+## Execution checklist
+
+1. [x] Vault path + catalog entry designed (this document)
+2. [ ] Confirm IMAP host/provider facts with founder (non-secret)
+3. [ ] Land catalog entry in `secrets-engine/catalog/`; register decision in
+       State Hub (approval model `decision`)
+4. [ ] Verify OpenBao prod reachability from the executing machine
+       (workstation has no local OpenBao on :8200 — prod custody lives in
+       the NetKingdom deployment; check via secrets-engine roles)
+5. [ ] **Red lane — founder, once:** provision the IMAP password through the
+       secrets-engine provisioning flow (never via chat/prompt/file)
+6. [ ] First read-only scan via `secrets-engine exec … scan-mailbox`;
+       file evidence report; add triage step to OperatingRhythm
+7. [ ] Recurring scan becomes an activity-core definition (see T05) and an
+       llm-connect execution target (see T06)
+
+## Boundary rules (binding)
+
+- Secret values never appear in git, State Hub, chat, prompts, logs, or
+  workplans — catalog metadata only.
+- email-connect stays read-only (`BODY.PEEK`); no mailbox write-back.
+- Sending mail from the company address is out of scope here; it would be a
+  separate catalog lane and a separate decision.

scripts/rhythm-session.sh

@@ -0,0 +1,40 @@
+#!/usr/bin/env bash
+# Binky operating-rhythm bridge session (BINKY-WP-0003-T04).
+# Runs a headless Claude Code session that does queue hygiene, writes the
+# daily brief, and pulls one AutopilotWorkQueue item when idle.
+# This is a BRIDGE until activity-core + llm-connect own scheduling/execution
+# (BINKY-WP-0003 T05/T06). Disable: see OperatingRhythm.md "Bridge scheduler".
+set -euo pipefail
+
+REPO="$HOME/binky-control"
+LOGDIR="$HOME/.cache/binky-control/rhythm"
+LOCK="$LOGDIR/rhythm.lock"
+mkdir -p "$LOGDIR"
+
+# never overlap a prior run
+exec 9>"$LOCK"
+flock -n 9 || { echo "$(date -Is) skipped: previous rhythm session still running" >>"$LOGDIR/cron.log"; exit 0; }
+
+PROMPT=$(cat <<'EOF'
+You are the Binky operating-rhythm bridge session (see OperatingRhythm.md).
+Work autonomously, Green/Blue lane only. Do, in order:
+1. Queue hygiene: check DecisionQueue.md (flag items older than 14 days),
+   OfficeHourQueue.md, RiskRegister.md escalation dates against today.
+2. Write today's daily brief to briefs/<YYYY-MM-DD>-daily-brief.md in the
+   format defined in OperatingRhythm.md (Decide now / Progress / Risks /
+   Best next hour; one screen max). Skip if today's brief already exists.
+3. If time remains, pull ONE item from AutopilotWorkQueue.md you can fully
+   complete in Green/Blue lane; mark it in_progress with agent
+   "agt-rhythm-bridge", do it, move it to the Completed log.
+4. Commit all changes with a concise message.
+Never touch Red/Yellow lane actions; queue them instead. Keep total effort
+bounded — this is a maintenance pass, not a project session.
+EOF
+)
+
+cd "$REPO"
+"$HOME/.local/bin/claude" -p "$PROMPT" \
+  --permission-mode acceptEdits \
+  --allowedTools "Read,Write,Edit,Glob,Grep,Bash(git add:*),Bash(git commit:*),Bash(git status),Bash(git log:*),Bash(git diff:*),Bash(date:*),Bash(ls:*)" \
+  >>"$LOGDIR/cron.log" 2>&1
+echo "$(date -Is) rhythm session finished rc=$?" >>"$LOGDIR/cron.log"

templates/OK-Audit-Template-v1.md

@@ -0,0 +1,117 @@
+# Operational Knowledge Audit — Template v1
+
+> Status: v1 — 2026-07-16 (BINKY-WP-0003-T02, AWQ-001). Company-agnostic
+> template generalized from the Binky dogfood run
+> (`audits/OK-Audit-v0-binky.md`). This is the delivery backbone of the
+> flagship offer in `OfferCatalog.md`.
+> Home note: the `audit-core` repo was assessed as a candidate home but owns
+> audit *event logging* (JSONL backend contract), not company audits — the
+> template lives here until a dedicated offer-delivery repo exists.
+
+## What this audit is
+
+A structured inventory of a company's operational knowledge: what exists,
+where the evidence lives, what's missing, and what to do about it — each
+action tagged with an owner and an autonomy lane so agents can execute the
+safe parts immediately.
+
+**Deliverables (fixed):**
+1. Findings document (this template, filled) — one section per area.
+2. Risk register entries (likelihood / impact / mitigation / escalation date).
+3. Action queues: decisions the founder must make, batched external-contact
+   items ("command day" runbook), and agent-executable backlog.
+4. Machine-readable summary (YAML, below) for tooling.
+
+## Method
+
+- **Evidence-first.** Every finding cites a source (document, account
+  statement, registry lookup, founder statement). Founder-stated facts are
+  marked as such until verified against records.
+- **Gaps are findings.** "Unknown / to verify" is a first-class result.
+- **Every action gets a lane.** Green (agent does it), Blue (agent does it,
+  founder informed), Yellow (agent prepares, founder approves), Orange
+  (founder executes with prepared material), Red (founder only).
+- **Time-boxed.** v1 targets one working day of agent time plus one founder
+  interview (~60 min). Depth grows in follow-up audits, not this one.
+
+## Areas
+
+### 1. Legal & registry
+Registry entry (name, seat, address, officers), articles of association,
+shareholder structure, company purpose vs. actual/planned activity,
+pending obligations (transparency register, announcements).
+*Typical gaps:* stale registered address, purpose incompatible with new
+business, missing document archive.
+
+### 2. Tax & accounting
+Accountant mandate status, filing status per year (annual accounts, tax
+returns, advance VAT), bookkeeping system and access ownership, receipt
+backlog, special patterns needing professional review (self-billing,
+intra-owner transactions).
+*Typical gaps:* no active mandate, filings behind, bookkeeping access owned
+by a third party.
+
+### 3. Banking & finance
+Accounts and access, cost base (recurring subscriptions, fees, rent),
+revenue history and paths, payment infrastructure, cash/runway view.
+*Typical gaps:* no consolidated cost table, dormant expensive accounts,
+no runway visibility.
+
+### 4. Digital presence & communications
+Domains owned, company email (own domain? credential custody? agent
+integration?), website, paper-mail handling, where official notices
+actually arrive.
+*Typical gaps:* correspondence over private addresses, mail with no intake
+pipeline, credentials outside any vault.
+
+### 5. Contracts & IP
+Existing contracts and obligations, IP ownership (company vs. founder
+privately — especially software/repos), evidence trail for commissioned
+work, template availability (NDA, service agreement).
+*Typical gaps:* unclarified IP before productizing, verbal agreements.
+
+### 6. Risks & queues (synthesis)
+Consolidate: new/updated risk entries, decision packages, external-contact
+batch, agent backlog. Close with a one-paragraph verdict: overall state,
+the 3–5 reactivation/operation-critical gaps, and the single best next
+action.
+
+## Per-area record format
+
+For each area record: **evidence** (with source + confidence),
+**gaps** (unknowns count), **actions** (each: description, owner,
+lane, queue destination).
+
+## Machine-readable summary
+
+```yaml
+audit: <company>
+version: 1
+date: ""
+auditor: ""            # agent/person
+founder_interview: ""  # date or n/a
+areas:
+  legal_registry:    {evidence: [], gaps: [], actions: []}
+  tax_accounting:    {evidence: [], gaps: [], actions: []}
+  banking_finance:   {evidence: [], gaps: [], actions: []}
+  digital_presence:  {evidence: [], gaps: [], actions: []}
+  contracts_ip:      {evidence: [], gaps: [], actions: []}
+risks: []              # ids of created/updated risk entries
+queues:
+  decisions: []        # decision-package ids
+  external_batch: []   # command-day items
+  agent_backlog: []    # autopilot items
+verdict: ""
+# action item shape:
+#   {desc: "", owner: founder|accountant|bank|agent, lane: green|blue|yellow|orange|red, queue: ""}
+# evidence item shape:
+#   {fact: "", source: "", confidence: stated|documented|verified}
+```
+
+## Evidence from the dogfood run
+
+Binky Hedgehog GmbH ran this audit on itself first
+(`audits/OK-Audit-v0-binky.md`): it surfaced a missing accountant mandate,
+a bookkeeping-access dependency, and an unclarified IP position — and turned
+them into queued, lane-tagged actions within the same day. That run is the
+reference example for offer delivery.

workplans/BINKY-WP-0003-autopilot-and-rhythm.md

@@ -22,7 +22,7 @@ StB replies and bank/authority notices reach the control plane.
 
 ```task
 id: BINKY-WP-0003-T01
-status: todo
+status: done
 priority: high
 ```
 
@@ -34,7 +34,7 @@ repo). Flagship-offer dependency (OfferCatalog.md). Green lane.
 
 ```task
 id: BINKY-WP-0003-T02
-status: todo
+status: done
 priority: medium
 ```
 
@@ -59,7 +59,7 @@ the schedule and how to disable it. Blue lane.
 
 ```task
 id: BINKY-WP-0003-T04
-status: todo
+status: done
 priority: high
 ```