docs(spec): §3.1 cross-reference to §1 producer scope (certifying proxy)

.beads/.beads-credential-key

@@ -0,0 +1 @@
+…çŒ@<¾pÀá¹È;Ïœ(´’,bTçcã±Ðí

.beads/dolt.corrupt-20260321T145000/.bd-dolt-ok

@@ -0,0 +1 @@
+ok

.beads/dolt.corrupt-20260321T145000/config.yaml

@@ -0,0 +1,96 @@
+# Dolt SQL server configuration
+#
+# Uncomment and edit lines as necessary to modify your configuration.
+# Full documentation: https://docs.dolthub.com/sql-reference/server/configuration
+#
+
+# log_level: info
+
+# log_format: text
+
+# max_logged_query_len: 0
+
+# encode_logged_query: false
+
+# behavior:
+  # read_only: false
+  # autocommit: true
+  # disable_client_multi_statements: false
+  # dolt_transaction_commit: false
+  # event_scheduler: "OFF"
+  # auto_gc_behavior:
+    # enable: true
+    # archive_level: 1
+
+listener:
+  host: 127.0.0.1
+  port: 64848
+  # max_connections: 1000
+  # back_log: 50
+  # max_connections_timeout_millis: 60000
+  # read_timeout_millis: 28800000
+  # write_timeout_millis: 28800000
+  # tls_key: key.pem
+  # tls_cert: cert.pem
+  # require_secure_transport: false
+  # allow_cleartext_passwords: false
+  # socket: /tmp/mysql.sock
+
+# data_dir: .
+
+# cfg_dir: .doltcfg
+
+# remotesapi:
+  # port: 8000
+  # read_only: false
+
+# mcp_server:
+  # port: 7007
+  # user: root
+  # password: ""
+  # database: ""
+
+# privilege_file: .doltcfg/privileges.db
+
+# branch_control_file: .doltcfg/branch_control.db
+
+# user_session_vars:
+# - name: root
+  # vars:
+    # dolt_log_level: warn
+    # dolt_show_system_tables: 1
+
+# system_variables:
+  # dolt_log_level: info
+  # dolt_transaction_commit: 1
+
+# jwks: []
+
+# metrics:
+  # labels: {}
+  # host: localhost
+  # port: 9091
+  # tls_cert: ""
+  # tls_key: ""
+  # tls_ca: ""
+
+# cluster:
+  # standby_remotes:
+  # - name: standby_replica_one
+    # remote_url_template: https://standby_replica_one.svc.cluster.local:50051/{database}
+  # - name: standby_replica_two
+    # remote_url_template: https://standby_replica_two.svc.cluster.local:50051/{database}
+  # bootstrap_role: primary
+  # bootstrap_epoch: 1
+  # remotesapi:
+    # address: 127.0.0.1
+    # port: 50051
+    # tls_key: remotesapi_key.pem
+    # tls_cert: remotesapi_chain.pem
+    # tls_ca: standby_cas.pem
+    # server_name_urls:
+    # - https://standby_replica_one.svc.cluster.local
+    # - https://standby_replica_two.svc.cluster.local
+    # server_name_dns:
+    # - standby_replica_one.svc.cluster.local
+    # - standby_replica_two.svc.cluster.local

.company/customers/aeoess.md

@@ -0,0 +1,38 @@
+# Design Partner: aeoess (Agent Passport System)
+First contact: Wave 10 (integration proposal on APS#5)
+First reply: Wave 19
+Status: ACTIVE DESIGN PARTNER — code shipped
+
+## Profile
+- Project: [agent-passport-system](https://github.com/aeoess/agent-passport-system)
+- Stack: TypeScript, Ed25519, XChaCha20-Poly1305, DID
+- Scale: 1122+ tests, 72 MCP tools, v1.19.4
+- Activity: Very high. Ships features daily. Responds within hours.
+
+## What They Built
+- `deriveEncryptionKeypair()` — Ed25519→X25519, 5/5 vectors (wave 23)
+- `qntm-bridge.ts` — 369 lines, 18/18 tests, HKDF+CBOR+XChaCha20+relay transport (wave 26)
+- `entityBinding` + `identityBoundary` — legal entity anchoring (wave 24)
+- DID cross-verification proposal with AgentID (wave 27)
+
+## What They Use qntm For
+- Encrypted transport layer beneath APS signed execution envelopes
+- Relay store-and-forward for offline agent delivery
+- Not using qntm CLI directly — using as protocol/relay infrastructure
+
+## Key Quotes
+- "qntm fills exactly that gap" (wave 19)
+- "Let's do the relay test" (wave 24)
+- Proposed layered envelope design: APS wraps qntm inner (wave 24)
+
+## Threads
+- APS#5 (primary): https://github.com/aeoess/agent-passport-system/issues/5
+- A2A#1575: entity binding
+- A2A#1606: data handling
+- A2A#1667: relay patterns
+
+## Lessons
+- Very technically rigorous — provides test vectors, expects them back
+- Self-driving once unblocked — doesn't need hand-holding
+- Treats qntm as infrastructure, not product — this is how technical adoption works
+- Response cadence: hours, not days

.company/customers/haroldmalikfrimpong-ops.md

@@ -0,0 +1,35 @@
+# Design Partner: haroldmalikfrimpong-ops (AgentID / getagentid.dev)
+First contact: Wave 22 (reply on A2A#1672)
+Status: ACTIVE DESIGN PARTNER — PR merged, relay proven
+
+## Profile
+- Project: [getagentid](https://github.com/haroldmalikfrimpong-ops/getagentid)
+- Platform: getagentid.dev
+- Stack: Python, Ed25519, X3DH, Double Ratchet, NaCl
+- Activity: Extremely high. Ships code within hours of discussion.
+
+## What They Built
+- 809-line AgentID→qntm encrypted chat demo (wave 25)
+- Relay test script: HKDF 3/3, HTTP 201, live message exchange (wave 26)
+- DID cross-verification: `did:agentid` ↔ `did:aps`, 10/10 checks, 82 tests (wave 27)
+- PR #3 on corpollc/qntm — AgentID bridge example (wave 27, MERGED)
+
+## What They Use qntm For
+- Encrypted relay transport for AgentID-verified agents
+- Interop proof: AgentID identity → qntm encrypted channel
+- Not using qntm CLI — using relay as infrastructure
+
+## Key Quotes
+- "Complementary pieces, not competing ones" (wave 22)
+- "Three identity systems, one encrypted channel" (wave 26)
+
+## Threads
+- A2A#1672 (primary): https://github.com/a2aproject/A2A/issues/1672
+- APS#5 (cross-pollination): https://github.com/aeoess/agent-passport-system/issues/5
+
+## Lessons
+- Fastest contributor cycle: concept → shipped code → PR in 2 waves
+- Self-directed — built DID interop without being asked
+- Network node — connects to crewAI, AgentID, A2A, APS simultaneously
+- Prefers Python, minimal dependencies (NaCl + cryptography only)
+- Updated his CBOR to native qntm field names voluntarily

.company/decision-rights-map.md

@@ -0,0 +1,29 @@
+# Decision Rights Map — qntm
+Created: 2026-03-22
+
+## Levels
+- **DECIDE**: Full authority, log it
+- **RECOMMEND**: Propose with evidence, Founder approves
+- **INFORM**: Gets notified after decision
+- **ESCALATE**: Goes to Chairman via Pepper
+
+## Map
+
+| Decision | DECIDE | RECOMMEND | INFORM | ESCALATE |
+|----------|--------|-----------|--------|----------|
+| Wave priorities (Top 5) | Founder | — | All | — |
+| Code merge to main | CTO/Founder | — | — | — |
+| Worker deploy | COO/Founder | — | — | — |
+| Test standards | CTO | — | Founder | — |
+| API/protocol changes | CTO | — | — | If crypto |
+| Positioning/messaging | CMO | — | Founder | — |
+| Product roadmap | CPO | — | Founder | Strategy pivot |
+| Distribution experiments | CMO | — | Founder | Paid spend |
+| Infrastructure changes | COO | — | Founder | — |
+| Pricing | — | CPO | CMO | Chairman |
+| Partnerships | — | Founder | — | Chairman |
+| Public statements | — | — | — | Chairman |
+| Package publishing | — | CTO | — | Chairman |
+| Spend > $50/mo | — | — | — | Chairman |
+| Crypto protocol changes | — | CTO | — | Chairman |
+| Strategy pivot | — | Founder | — | Chairman |

.company/decisions/2026-03-22-echo-bot-persistence.md

@@ -0,0 +1,50 @@
+# Decision: Echo Bot Persistence Strategy
+Date: 2026-03-22 (Wave 4)
+DRI: Founder
+
+## Problem
+The echo bot (our only activation path) runs as a nohup process on the founder's MacBook. It died between waves, returning the primary metric to 0. Every new `uvx qntm` user who follows the README hits a dead bot.
+
+## Target Customer
+New agent developers who run `uvx qntm` and need immediate proof of value.
+
+## Evidence
+- Echo bot died between wave 3 and wave 4 (predicted but not prevented)
+- 862 weekly PyPI downloads → 0 new echo bot participants (bot was dead during this window)
+- Primary metric dropped from 1 → 0 active conversations
+- The only activation path requires a responsive echo bot
+
+## Options Considered
+
+### Option A: launchd plist (macOS) — IMPLEMENTED
+- **Pros:** Immediate fix, auto-restart on crash, survives reboots
+- **Cons:** Depends on founder's MacBook being on, no global availability, uses DO polling (17K req/day)
+- **Cost:** Zero
+- **Time to implement:** 15 minutes
+
+### Option B: Cloudflare Worker echo bot
+- **Pros:** Global, always-on, zero-maintenance, uses Cron Triggers (not polling), no DO quota impact
+- **Cons:** Must handle crypto in Worker context (TypeScript), needs separate deploy, complexity
+- **Cost:** Free tier (Workers + Cron Triggers)
+- **Time to implement:** 2-4 hours
+
+### Option C: Cloudflare Worker with WebSocket subscription
+- **Pros:** Best of B + real-time response (no poll delay), prepares for WebSocket migration (bead qntm-szex)
+- **Cons:** Most complex, WebSocket support may need DO for the subscriber
+- **Cost:** Free tier
+- **Time to implement:** 4-8 hours
+
+## Decision
+**Phase 1 (now): Option A** — launchd plist installed and verified. Bot survives reboots.
+**Phase 2 (next wave): Option B** — CF Worker echo bot with Cron Trigger (poll every 60s from Worker instead of 5s from MacBook). This eliminates host dependency AND reduces DO load.
+**Phase 3 (later): Option C** — When WebSocket migration happens (bead qntm-szex), upgrade echo bot to subscribe.
+
+## Expected Metric Effect
+- Primary metric stabilizes at ≥1 (echo bot conversation always active)
+- Activation path reliability: 100% uptime for new users
+- DO request load: reduces from 17K/day (5s polling) to ~1.5K/day (60s Cron Trigger)
+
+## Reversible? Yes — can switch between any option
+## Confidence: 0.9
+## Escalation: No (CF Workers deploy is ALLOWED per AUTONOMY)
+## Review: Wave 6

.company/decisions/2026-03-22-mcp-server.md

@@ -0,0 +1,32 @@
+# Decision Memo: Build qntm MCP Server
+
+## DECISION MEMO
+- **Problem:** Distribution is the existential bottleneck. 16 waves, 0 customer contact. GitHub issue-based outreach has 0% response rate after 24+ hours. Need a new distribution channel.
+- **Target customer:** AI agent developers using MCP-compatible tools (Claude Desktop, Cursor, OpenClaw, etc.)
+- **Evidence:**
+  - DeadDrop (yksanjo/deaddrop-v2) launched an encrypted agent messaging MCP server and got listed on LobeHub marketplace with 2 installs from zero marketing
+  - MCP is the de facto standard for AI tool integration (Google, GitHub, Microsoft all ship MCP servers)
+  - LobeHub and Smithery are active marketplaces where agent developers discover tools
+  - 6 GitHub outreach efforts = 0 responses; MCP marketplace is a different, unblocked channel
+  - Agent developers browsing MCP marketplaces ARE our exact target segment
+- **Options considered:**
+  1. Build MCP server (new distribution channel, within ALLOWED) ← CHOSEN
+  2. More GitHub issues (proven low conversion, diminishing returns)
+  3. Wait for PyPI approval (blocked for 11 waves)
+  4. Build framework-specific integrations (LangChain/CrewAI — higher effort, narrower reach)
+- **Recommended option:** Build qntm MCP server
+- **Expected effect on primary metric:** Opens a new funnel: MCP marketplace → install → identity → conversation. If even 1% of MCP marketplace browsers try qntm, that's more activation than all GitHub outreach combined.
+- **Cost/impact:** ~1 wave of development time. Optional dependency (mcp[cli]). No infrastructure changes.
+- **Reversible or irreversible:** Reversible. It's a module that can be removed without affecting core functionality.
+- **Confidence:** 0.7 — DeadDrop proves the pattern works. Unclear how much traffic MCP marketplaces drive.
+- **DRI:** CEO (Founder)
+- **Review date:** Wave 18 (check if MCP server generates installs/conversations)
+- **Escalation needed?** Yes — marketplace listing may need approval if it counts as "public posting" under AUTONOMY.md
+
+## Outcome
+- Built and shipped in wave 16
+- 9 tools, 2 resources, 1 prompt
+- 14 tests, all 221 tests pass
+- Committed dd8c3df, pushed to main
+- Both READMEs updated with MCP section
+- Full docs at docs/mcp-server.md

.company/decisions/2026-03-22-relaunch-priorities.md

@@ -0,0 +1,23 @@
+# Decision: Relaunch Priorities
+Date: 2026-03-22
+DRI: Founder
+
+## Problem
+Waves 0-6 were tech-focused — fixed bugs, stabilized tests, but built zero customer evidence. The kernel demands business fundamentals before more engineering.
+
+## Options Considered
+1. **Keep shipping features** (echo bot, more gateway recipes) — wrong: no customers to test with
+2. **Full business relaunch** — create all Day One documents, set up goal hierarchy, then execute customer-facing work
+3. **Split: fix tests + customer outreach simultaneously** — best of both worlds
+
+## Decision
+Option 3. Fix the test regression (vitest compat) as an ops task while prioritizing customer-facing work: measure TTFM, create target customer list, start distribution research.
+
+## Expected Metric Effect
+- Tests back to green (O1 health metric)
+- Begin measuring L3 (TTFM) within this wave
+- Target customer list created → enables outbound experiments
+
+## Reversible? Yes
+## Confidence: 0.8
+## Escalation: No

.company/decisions/2026-03-22-subscribe-auth.md

@@ -0,0 +1,70 @@
+# DECISION MEMO — Authenticated Subscribe
+
+## Problem
+`/v1/subscribe` currently routes by `conv_id` alone with no identity verification. Any client that knows a conversation ID can connect and receive ciphertext. While E2E encryption means they can't read the content, they can observe traffic patterns (timing, frequency, message sizes).
+
+## Target Customer/Segment
+Agent developers integrating encrypted messaging into multi-agent systems. Specifically: aeoess (APS) and The-Nexus-Guard (AIP) — our first two external technical contacts.
+
+## Evidence
+- The-Nexus-Guard explicitly asked on A2A #1667: "does qntm support any form of identity for subscribers? ... is there agent-level authentication on subscribe?"
+- aeoess's integration proposal on #5 implies identity-bound transport — their system binds everything to Ed25519 passport keys.
+- Both represent potential design partners. Addressing their feedback directly demonstrates responsiveness and engineering quality.
+
+## Options Considered
+
+### Option A: Ed25519 Challenge-Response on WebSocket Handshake
+```
+1. Client: GET /v1/subscribe?conv_id=X&pub_key=Y
+2. Server: sends {"challenge": "<32-byte-hex>"}
+3. Client: sends {"signature": "<ed25519-sig-of-challenge>"}
+4. Server: verifies sig against conversation participant list
+5. If valid → stream messages. If not → close(4003).
+```
+
+**Pros:** Strong identity verification. Same Ed25519 primitives already in the relay (verifyAnnounceSig). Compatible with APS key derivation path.
+**Cons:** Adds 1 round-trip latency to subscribe. Requires participant list to be stored on relay. Breaking change for existing clients.
+
+### Option B: Bearer Token (Signed Subscribe Token)
+```
+Client pre-signs a subscribe token: sign(conv_id + timestamp + nonce, private_key)
+GET /v1/subscribe?conv_id=X&token=Y&pub_key=Z
+Server verifies signature in the HTTP upgrade, streams immediately.
+```
+
+**Pros:** No extra round-trip (verification happens during WebSocket upgrade). Stateless verification.
+**Cons:** Token could be replayed within its TTL. Need to define TTL/nonce policy.
+
+### Option C: Status Quo (No Auth)
+**Pros:** Simplest. E2E encryption provides content confidentiality regardless.
+**Cons:** Traffic analysis exposure. Doesn't meet expectations of identity-focused developers (APS, AIP). Perception of engineering incompleteness.
+
+## Recommended Option
+**Option A (Challenge-Response)** — it's the strongest identity guarantee, uses existing relay primitives, and directly addresses what both external developers asked for. The 1 round-trip cost is negligible for WebSocket connections that last minutes/hours.
+
+Implement as OPTIONAL: if `pub_key` param is present, require challenge-response. If absent, fall through to unauthenticated subscribe (backwards compatible).
+
+## Expected Effect on Primary Metric
+- Direct: enables APS integration (identity key → subscribe auth → encrypted relay). Unblocks potential first design partner conversation.
+- Indirect: demonstrates engineering quality to external evaluators. Both responders are evaluating us partly on code quality.
+
+## Cost / Impact
+- ~100 lines in worker/src/index.ts (challenge generation, signature verification, participant check)
+- ~50 lines in python-dist client (send pub_key + sign challenge)
+- Tests: 5-10 new integration tests
+- No infrastructure cost.
+
+## Reversible or Irreversible?
+Reversible — optional parameter, backwards compatible.
+
+## Confidence
+0.85 — high confidence this is the right feature. The only risk is over-engineering for two developers who may not convert to users.
+
+## DRI
+CEO (Founder)
+
+## Review Date
+Wave 21 (after implementation + feedback from aeoess/The-Nexus-Guard)
+
+## Escalation Needed?
+No — this is a protocol enhancement within existing architectural patterns. Not a cryptographic protocol change (uses same Ed25519 primitives). Not a strategy pivot.