Build plan: from the built system to the space and memory model

1l · Two-way base: envelope, conversations, change feed, To review size M

• Envelope reader for REST and /mcp (headers + _meta, conflict refusal, refusal of a declared org / user that differs from the sign-in).
• conversations, idempotency_keys; conversation start / end; Idempotency-Key on every write.
• /v1/changes?cursor= with 410 on an old cursor or a permission change; a cursor in every tool answer; its own small rate budget (decision 18).
• "Memory changed" notice in every MCP tool answer (from the old 1l plan).
• "To review" list plus confirm / discard (fixes the stuck staged summaries); the tool and model shown on items.
• Address columns added to memories (nullable, filled from now on: conversation, origin, app, model).

Exit test: a script bot runs start → saves (retried with the same key, no duplicates) → end. The next run gets only the changes since its cursor, including removals. A revoked grant gives 410, not stale data. Staged summaries can be confirmed.

1m · Space registry: company side size M–L

• tenants, spaces, space_aliases, space_links, space_rules; migrate place_mappings (written to both for one stage).
• Company tenants registered by the ADMIN: GitHub org (today IT-Labs-AJ) and the Bitbucket workspace when it exists, and the Atlassian site. Jira projects become spaces from the existing connector.
• Optional repo list import (GitHub / Bitbucket API, read-only): repo id, root commits, URL aliases. A spike first checks whether repo ids survive renames and transfers.
• resolve_place becomes envelope space / place → space → current link → place, and keeps the old fallbacks (app default, home team).
• Hindsight documents get the tag space:{id}.
• Web: ADMIN "Spaces" screen (tenants, spaces, aliases, links with history); a "Spaces" tab on each place.

Exit test: every company repo and Jira project has one space ID and a place. Two spellings of the same remote (SSH and HTTPS, with and without .git) and a mirror resolve to one space. A faked remote routes, but reads nothing without membership.

1n · People's side, first slice: manifest, helper, Claude Code capture, work pool size L

• Manifest v2 and /v1/spaces/resolve; index cards v0 (person and current place) built from existing data: open items, must-apply items, recent decisions and places.
• cmcp helper plus a Claude Code plugin (hooks above, headersHelper, a /cmcp skill); stretches; background uploader; echo filter; secret scan.
• Checkpoint routing (tag → mention → pool), routing_decisions, the about-person rule, one item linked to several spaces through memory_links.
• Person-owned spaces: .cmcp-space marker and personal repos; ask-once links (confirmed); the person decides, and the lead accepts when others will see items.
• Claude Code auto-memory files copied in as memory_file items, replacing older versions instead of piling up.
• Capture modes: review first (default for real accounts), automatic with undo (test accounts); quality gate; ageing (decision 19).
• Web: "My spaces", "Work pool", "To review", an "auto-saved by <tool>" label.

Exit test (the first visible proof): on this server, a Claude Code session in owner-solo works across two repos and a scratch folder. Items land in the right lanes and the work pool without anyone saving, and every item answers the seven questions. A second machine (or a second clone) gets the same space IDs. The ~24 outdated items from 2026-10-03 are replaced or marked by the imported memory files.

1o · Collective → organizational memory size M

• counts_toward view; aggregate panels on place pages and place cards ("7 people noted …"; never below 3; humans only).
• The promotion job reads candidates by space link across lanes instead of inside one team; it keeps the neutral rewrite and lead approval; evidence goes in promoted_from links.
• Approved items flow back down through cards and the change feed to every app in a linked space.
• Matching ladder 0.4–0.8 as suggestions (worker similarity, branch-name Jira keys, same people active); a weekly work-pool digest.
• Replace with dates, duplicates as confirmations, ageing of unused automatic items.

Exit test: three test people noting the same rule in their own lanes produce one promotion proposal. The lead approves it. Every linked app sees the new place card line on its next prompt. Two people produce no aggregate. Nothing crosses a client wall.

1p · Space knowledge v1: Jira, shared mailbox, first channel size L

• Layers for existing connectors: raw (sources, as today) → cleaned (quotes, signatures and duplicates removed, no AI) → typed records (memories of kind decision / action_item / status_signal / fact, with fields, a quote, extractor version and confidence).
• Rules filter before the model (newsletters, bots, one-liners). Extraction runs when a thread goes quiet. Status signals from Jira transitions and Git merges are trusted without the model.
• Decision log, open actions, project status on place and person cards; nightly status, weekly digest.
• Only spaces whose audience equals a place's members (team channels, shared mailboxes, Jira projects linked to one place). Private channels and per-source audiences wait (see section 11).
• First chat platform per decision N3 (Teams through Microsoft Graph delta, or Slack). This is a new connector, so it needs a host check and the user's go-ahead first.
• "Who to ask" counts are built but switched off until the legal check (decision 19).

Exit test: in a synthetic workspace, a quiet thread yields a decision and an action with source quotes. The lead approves the decision into the decision log. The action shows on the owner's person card. Deleting the source removes the derived records. Extraction stays on the local model for real accounts.

1q · Every surface: allowed apps, device keys, other tools, bot library size L

• Allowed-AI-apps list per account, enforced at sign-in and on keys, with M-105 risk notices when it is loosened. This is the gate for the real account.
• Personal device keys plus device flow (cloud sessions, cron, SSH without a browser).
• cmcp hook adapters for Codex, Gemini CLI, Cursor and Copilot; copying of GEMINI.md / AGENTS.md style files; the bridge for tools without hooks.
• Python bot library (start → checkpoint → changes), a Claude memory-tool handler, signed webhooks.
• claude.ai connector through Keycloak (only if the allow-list permits it).

Exit test: one session each in Claude Code, Codex and a scripted bot write to the same space with correct addresses. An app that is not allowed is refused for a real-style test account.

1r · Digital workers size M

• Principal kind worker and worker_profiles: created only by an ADMIN in person, master + backup, end date, limits, 90-day review. Paused when no master is named within 7 days.
• Its mail threads and chats are spaces; its input is untrusted data; it is marked AI everywhere and never counts toward the three people needed for promotion.
• Every permission check reviewed by authz-architect; new isolation tests.

Exit test: a test worker reads #shipping, writes a status item marked AI, and can never approve, grant, read Personal memory or create another worker.

1u · First real use in pilot size M

A. A real account that is ready

• A readiness report (one command and a section on the ADMIN's Account page): every loosened switch, allowed AI apps, device keys, bots and their sponsors, connectors, and settings that differ from the defaults, marked green / amber / red.
• pilot starts with the allowed-apps list on (Q-35 decision 7): Claude Code through device keys and the web console only; the ADMIN adds others.
• Checked and locked for the pilot: review first, extraction on the local model only, whole-conversation copies off.

B. Real people can start on their own

• The invitation path tested end to end for a new colleague: account, first sign-in with the one-time code, device approval, and the helper and plugin on their laptop (Windows and macOS steps; the helper stays a Python package for now, Q-35 decision 8).
• cmcp doctor: checks name lookup, certificates, the three public addresses, sign-in, the stored key, the clock and the Claude Code hooks, and says in plain words what is wrong (the "browser never reached the server" case took an hour).
• A "first day" page in the manual.

C. Operations that matter once data is real (the open go-live items)

• A real reboot in a planned window, proving that everything starts on its own.
• Resource limits for the cMCP containers (risk R-10), and a firewall review.
• Off-server encrypted backups and a restore test with the offline key (moved to Phase 2 on 2026-10-02; decision U3).

D. Measures (a weekly report page, counts only, never memory text)

• Per person and space: notes saved automatically, kept, discarded and aged; notes used in context and search; promotion suggestions made and accepted; requests and how long decisions take.
• Answer quality on real data: 20–30 questions the user writes once, scored weekly with the existing retrieval harness (local model only).
• Speed: context load, search and checkpoint, median and 95th percentile.

E. Carried over from 1t

• A 24-hour wait after ADMIN changes before a high-risk loosening (closes the "demote the second ADMIN" gap).
• Test hygiene: browser tests reuse sign-ins everywhere; notice checks read the database.

Exit test (go / no-go for Phase 2): two or more people use Claude Code with the plugin in pilot on at least ten working days; the readiness report is green; a restore and a reboot succeeded; at least 60% of automatic notes are kept rather than discarded or aged (otherwise tune what is saved); at least one promotion suggestion accepted per active place each week, or a clear reason why not; no secret stored and no read across accounts or clients in the audit; answer quality on the real questions at least the synthetic baseline (23 of 24 in the top five).

A · Restart the web server into its newer kernel on hold

• Before: boot firewall equals the running one; the live applications on that server are saved to start again; integrity baselines copied; the provider's remote console ready.
• After, checked from outside: the newer kernel and a healthy disk mirror; the 23 outside checks; the hosted applications answer; firewall and ban rules as before.
• Fallback: boot the older kernel from the boot menu; expected downtime 2–5 minutes, at a quiet hour the owner picks.

B · The console at cmcp.it-labs.in on hold

• A DNS record and a hosting-panel site with a certificate (owner's go-ahead for each).
• A service account of its own, a current Node in that account's folder (the system Node unchanged), the console as a system service on 127.0.0.1 only, behind the web server.
• Sign-in: the new address registered as a return address; the edge router's sign-in limit exempts the console's own token exchanges, as it did on the pilot server.
• A private link (WireGuard, one port, both ends locked) for the web-admin back end, which is never made public.
• Checks: the browser test suite against the new address; the web server's existing sites unchanged.

Exit test: people sign in at cmcp.it-labs.in and use every screen against the pilot API; the other sites on that server answer exactly as before.

C · The stack on a GPU server (Hetzner GEX45) when rented

• A current operating system, the GPU driver and Docker; firewall and SSH keys first.
• The cMCP stack from the code repository, at new addresses (for example cmcp-api.it-labs.in, cmcp-auth.it-labs.in).
• The local model chosen by running the existing quality test on the GPU (estimates on the LLM results page: today's model about 5× faster; larger models such as Qwen 27B fit).
• Only the code and the test accounts move; old backups of the pilot server stay there.
• Encrypted off-server backups and a restore test; then the console points at the new addresses, the full test suites run, and the pilot server's stack is switched off.

Exit test: the full test suites pass against the GPU server; extraction runs on the GPU; a restore from the off-server backup works.