Harness foundation: INTENT, ADR-001, architecture, prototype adoption

- INTENT.md: three-layer model (blueprint/instance/harness), single
  shared runtime, never-become boundaries
- ADR-001 (accepted): DEC-2026-002 resolution — one harness repo for
  all projects; instances are declarative state in consuming repos
- docs/architecture.md: components, contracts (manifest, tool
  profiles, completion events, credential lanes), deployment shape
- agent_harness/: executor-worker prototype adopted and renamed
  (6/6 tests green); HARNESS-WP-0001 initial workplan (7 tasks)

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

docs/adr/ADR-001-agent-harness-architecture.md

@@ -0,0 +1,57 @@
+---
+id: ADR-001
+title: Single shared agent harness; instances are declarative state in consuming repos
+status: accepted
+date: "2026-07-17"
+---
+
+# ADR-001 — Single shared agent harness
+
+## Status
+
+Accepted (DEC-2026-002, binky-control DecisionQueue, resolved by Bernd
+2026-07-17; hub decision `63620255-59d0-4109-bdee-4d0644c450e5`).
+
+## Context
+
+Unattended agentic work needs blueprints (kaizen-agentic), compute
+(llm-connect), scheduling (activity-core), credentials, policy, memory,
+and reporting — a complex, rapidly evolving combination. The candidate
+homes for the execution runtime all had disqualifying boundaries in their
+ratified INTENT files: activity-core "does not execute the work";
+kaizen-agentic does no scheduling and no LLM invocation; llm-connect is
+an interface layer. Per-project executor repos would multiply glue code
+and upgrades linearly with agent count. The concrete trigger: binky-
+control's operating rhythm depended on a workstation cron bridge
+(BINKY-WP-0004).
+
+## Decision
+
+1. **One new repo — `agent-harness` — is the single shared agent runtime
+   for all projects.** No further runtime repos per agent or per project.
+2. **Agent instances live in consuming repos as declarative state only**
+   (manifest + `.kaizen/` memory/metrics): blueprint reference, cadence,
+   lane, named tool profile, budget, pinned harness major. No code, no
+   credentials, no tool enumerations.
+3. **Blueprints stay in kaizen-agentic; scheduling stays in
+   activity-core; provider abstraction stays in llm-connect.** The
+   harness consumes all three and is the only credential holder and
+   policy enforcement point for agent sessions.
+4. The 2026-07-17 executor-worker prototype is adopted as the harness
+   seed (`agent_harness/` package). binky-control is tenant #1.
+
+Details: [docs/architecture.md](../architecture.md).
+
+## Consequences
+
+- Adding an agent to any project = editing that project's manifest;
+  onboarding a project = committing one manifest.
+- Base-technology evolution (adapters, tool policies, credential
+  mechanics) lands once, here — instances upgrade by version bump.
+- The harness becomes a critical shared service: it needs its own
+  versioning discipline, conformance tests, and kaizen measurement.
+- BINKY-WP-0004-T06 (cron-bridge cutover) now gates on this repo's
+  Railiance deployment instead of a binky-specific worker.
+- Repo-boundary discipline continues: any pressure to add scheduling,
+  blueprint authoring, or tenant-specific logic here is a signal to
+  extend the neighbor repo or the instance model instead.