diff --git a/AutopilotWorkQueue.md b/AutopilotWorkQueue.md index b6739c5..f389f35 100644 --- a/AutopilotWorkQueue.md +++ b/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. diff --git a/OperatingRhythm.md b/OperatingRhythm.md index b3ca2c2..8c08498 100644 --- a/OperatingRhythm.md +++ b/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 diff --git a/integrations/company-email-openbao.md b/integrations/company-email-openbao.md new file mode 100644 index 0000000..4be0df0 --- /dev/null +++ b/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: # 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. diff --git a/scripts/rhythm-session.sh b/scripts/rhythm-session.sh new file mode 100644 index 0000000..bbff663 --- /dev/null +++ b/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/-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" diff --git a/templates/OK-Audit-Template-v1.md b/templates/OK-Audit-Template-v1.md new file mode 100644 index 0000000..65d0e7c --- /dev/null +++ b/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: +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. diff --git a/workplans/BINKY-WP-0003-autopilot-and-rhythm.md b/workplans/BINKY-WP-0003-autopilot-and-rhythm.md index 7e28c73..7bc1537 100644 --- a/workplans/BINKY-WP-0003-autopilot-and-rhythm.md +++ b/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 ```