BINKY-WP-0004-T03: executor worker secret lanes prepared

- Lane 1 (LLM provider): reuse verified — warden catalog
  openrouter-llm-connect, policy workload-kv-read-llm-connect-provider-secrets
- Lane 2 (forgejo deploy key): new, per-repo write deploy key design,
  founder Red lane
- Lane 3 (mail-scan AppRole): executor-worker-binky-mail bound to the
  existing IMAP read policy — closes email checklist item 9's auth
  blocker on paper; provisioning founder Red lane
- No secret values anywhere; T04 can proceed on Lane 1 alone

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

integrations/company-email-openbao.md

@@ -97,7 +97,10 @@ Scan output under `mailmeta/` — metadata only (no message bodies in git).
        `mailmeta/reports/` (scan c3c7e784…). Notable: Stripe webhook
        failure notice, Qonto Beleg reminders, HUB31 correspondence,
        2 suspicious external mails (ignored, never acted on)
-9. [ ] Recurring scan via activity-core (BINKY-WP-0003 follow-ons)
+9. [ ] Recurring scan via activity-core (BINKY-WP-0004 T03/T05; auth
+       blocker solved on paper — non-interactive AppRole lane designed in
+       `integrations/executor-worker-secrets.md`, provisioning is founder
+       Red lane)
 
 ### Founder provision (step 6) — interactive human shell
 

integrations/executor-worker-secrets.md

@@ -0,0 +1,86 @@
+# Executor Worker — OpenBao Secret Lanes (BINKY-WP-0004-T03)
+
+> Status: prepared 2026-07-17. Catalog metadata and provisioning steps only —
+> **no secret values appear here or anywhere in git/hub/chat**. All new
+> provisioning is founder Red lane per AutonomyPolicy.md.
+
+The executor worker (DEC-2026-002: new small repo, deployed on Railiance)
+needs three credential lanes. One exists and is reusable; two need
+provisioning.
+
+## Lane 1 — LLM provider key: REUSE (verified)
+
+Warden catalog `openrouter-llm-connect` (active, resolvable, reviewed
+2026-07-02):
+
+- Path: `platform/workloads/activity-core/llm-connect/llm-connect-provider-secrets`
+- Field: `OPENROUTER_API_KEY`
+- Auth: any token carrying policy `workload-kv-read-llm-connect-provider-secrets`
+- Policy gate: `flex-auth check secret.read:llm-connect` (advisory today)
+
+**Verdict: reuse.** The key is scoped to "llm-connect in activity-core"; the
+executor worker is the consumer that scoping anticipated (it executes tasks
+activity-core emits, via llm-connect adapters). No new secret needed. If the
+worker later gets its own workload identity, bind that identity to the same
+policy — same secret, separate auth principal — rather than duplicating the
+key.
+
+## Lane 2 — Forgejo deploy key: NEW (Red lane)
+
+No warden catalog entry exists (checked 2026-07-17; nearest match falls
+through to `key-cape-oidc-login`). The worker must push commits to target
+repos on forgejo (railiance01:30022), starting with a sandbox repo (T04),
+later binky-control (T06).
+
+Proposed provisioning (founder Red lane, ~10 min):
+
+1. Generate an ed25519 keypair on Railiance (worker host), private key never
+   leaves the host; store a copy under OpenBao
+   `platform/workloads/executor-worker/forgejo-deploy-key`
+   (fields: `SSH_PRIVATE_KEY`, `SSH_PUBLIC_KEY`).
+2. In forgejo, add the public key as a **per-repo deploy key with write
+   access** — sandbox repo only at first; add binky-control at T06 cutover.
+   Per-repo deploy keys beat a machine-user account here: blast radius is
+   exactly the repo list.
+3. New OpenBao policy `workload-kv-read-executor-worker-forgejo` scoped to
+   that path; warden catalog entry `executor-worker-forgejo-deploy` (owner:
+   railiance-platform, risk: high).
+
+## Lane 3 — Non-interactive AppRole for company-email scan: NEW (Red lane)
+
+Blocker being closed: the existing OIDC role
+`binky-company-email-imap-workload-kv-read` is browser-interactive with a
+15-minute TTL — unusable for recurring scans (email-integration checklist
+item 9, `integrations/company-email-openbao.md`).
+
+Proposed provisioning (founder Red lane, ~10 min):
+
+1. Enable/confirm AppRole auth on the OpenBao instance (`bao auth list`;
+   enable at path `approle` if absent).
+2. Create role `executor-worker-binky-mail` bound to the **existing** policy
+   `workload-kv-read-binky-company-email-imap` (no policy change needed):
+   `token_ttl=15m`, `token_max_ttl=30m`, `secret_id_ttl=0` (or rotate
+   quarterly), `token_num_uses` bounded.
+3. Deliver `role_id` + `secret_id` to the worker host via the
+   secrets-engine delivery mechanism (files `0600` on Railiance, outside any
+   repo). The worker logs in per run:
+   `bao write auth/approle/login role_id=… secret_id=…` → short-lived token
+   → `bao kv get -field=IMAP_USERNAME|IMAP_PASSWORD tenants/binky/company-email/imap`.
+4. Warden catalog entry `executor-worker-binky-mail-approle` (owner:
+   railiance-platform, risk: high) so the lane is discoverable and audited.
+
+Scan invocation stays exactly the manual pattern (read-only email-connect,
+values only ever in process env):
+config `integrations/mailbox-binky-company.yml`, reports to
+`mailmeta/reports/`.
+
+## Founder Red-lane summary
+
+- [ ] Lane 2: forgejo deploy key (generate, register on sandbox repo, store
+      in OpenBao, catalog entry)
+- [ ] Lane 3: AppRole `executor-worker-binky-mail` (create role, deliver
+      role_id/secret_id to Railiance, catalog entry)
+- [x] Lane 1: nothing to do — reuse confirmed
+
+T04 (worker MVP) can start with Lane 1 alone plus a workstation-side dry
+run; Lanes 2–3 gate unattended operation, not development.

workplans/BINKY-WP-0004-workstation-independent-executor.md

@@ -42,7 +42,7 @@ or direct PR in that repo per its governance. Green lane (code + tests).
 
 ```task
 id: BINKY-WP-0004-T02
-status: todo
+status: done
 priority: high
 state_hub_task_id: "b44af058-22e4-4d63-a28c-8f6c69d65ea1"
 ```
@@ -60,7 +60,7 @@ Catalog metadata only; any new secret provisioning is founder Red lane.
 
 ```task
 id: BINKY-WP-0004-T03
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "e4740aa0-94f7-4ebe-9217-aaca3ef902cc"
 ```