AutopilotWorkQueue.md

@@ -5,6 +5,13 @@
 
 ## 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"
@@ -44,6 +51,18 @@ 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"
@@ -63,12 +82,4 @@ with a one-line outcome.
 
 ## Completed
 
-- **AWQ-001** (2026-07-16, BINKY-WP-0003-T02): audit template v1 at
+*(none yet)*
-  `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,31 +33,6 @@ 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

@@ -1,119 +0,0 @@
-# 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

@@ -1,40 +0,0 @@
-#!/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

@@ -1,117 +0,0 @@
-# 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: done
+status: todo
 priority: high
 ```
 
@@ -34,7 +34,7 @@ repo). Flagship-offer dependency (OfferCatalog.md). Green lane.
 
 ```task
 id: BINKY-WP-0003-T02
-status: done
+status: todo
 priority: medium
 ```
 
@@ -59,7 +59,7 @@ the schedule and how to disable it. Blue lane.
 
 ```task
 id: BINKY-WP-0003-T04
-status: done
+status: todo
 priority: high
 ```