docs(WS-0): truth pass across six workstreams — the board was describing a codebase from weeks ago

ai-company-brain/AGENTS.md

@@ -114,8 +114,9 @@ to it and to `competitive_hardening_2026-07.md` (CH-*) rather than re-describe t
 | [`task_manager_harness_2026-07.md`](specs/task_manager_harness_2026-07.md) | Task-manager × harness engineering (app-layer sibling) | 🔄 Tier 1 shipped (2026-07-03); Tier 2 planned |
 | [`llm_caching_memory.md`](specs/llm_caching_memory.md) | Prompt caching (ADR-008) + session memory | 🔄 caching **shipped & wired**; session-memory shipped but **inert by default** (→ BO-21); Phase 7 open |
 | [`mcp_plugin_integration.md`](specs/mcp_plugin_integration.md) | MCP servers vs Claude plugins vs REST | 🔄 MCP half **built** (`_inject_mcp_servers`); plugin store not started |
+| [`tenancy_and_visibility.md`](specs/tenancy_and_visibility.md) | **Tenancy + visibility — the architecture of record for who can see what.** Records two owner calls of 2026-08-03: (a) **the tenant boundary is THE DEPLOYMENT** — one deployment per tenant, row-level org isolation explicitly NOT built, `organization_id` stays a label not a mechanism; (b) the **visibility model** private → Center → org plus ad-hoc cross-Center groups by invite, mapped onto the shipped `email \| group:<slug> \| org` subject vocabulary. Also answers "what makes a project a team's project" (an explicit `group:` grant), carries the per-surface gap table for going app by app, and names what is out of scope (row-level tenancy, org switcher, multi-org users). **Read before designing any sharing or scoping on a new surface** | 🟢 architecture of record (owner-answered 2026-08-03) |
 | [`org_access_control.md`](specs/org_access_control.md) | **Org access control / multi-tenant user management** — members, roles, per-user allow/deny overrides, feature + agent gating, per-member integration credentials, default-deny auth. **§10 is the handoff contract for the multiplayer agent collaboration workstream — read it before designing multiplayer** | 🟢 Phase 1 shipped; remaining scope (modules/teams, session sharing, transcript + memory exposure) **transferred to multiplayer collaboration** |
-| [`multi_user_organization_research.md`](specs/multi_user_organization_research.md) | Multi-user / org account research — identity, roles, tenancy, memory + credential scoping, SaaS multi-tenancy | 🔄 §4 identity/roles now implemented via `org_access_control.md`; §5 modules, §7 memory scoping, §8 credential scoping, §9 entity-graph RLS and §17 SaaS remain research |
+| [`multi_user_organization_research.md`](specs/multi_user_organization_research.md) | Multi-user / org account research — identity, roles, tenancy, memory + credential scoping, SaaS multi-tenancy | 🔄 §4 identity/roles now implemented via `org_access_control.md`; §5 modules, §7 memory scoping, §8 credential scoping remain research. ⚠️ **§9 entity-graph RLS and §17 SaaS tenancy are SUPERSEDED for planning purposes by `tenancy_and_visibility.md` §1 + §6** (2026-08-03 owner call: one deployment per tenant; row-level org isolation explicitly not built). Read them as research into a path that was considered and declined, not as queued work |
 | [`chat_agent_framework_review_2026-07.md`](specs/chat_agent_framework_review_2026-07.md) | **Chat + agent framework review** — dual-runtime verdict (MAF framework, Copilot as coding engine), orchestration/memory/artifact/HITL/co-authoring gaps, prioritized plan | 🟢 review complete |
 | [`single_agent_chat_bug_audit_2026-07.md`](specs/single_agent_chat_bug_audit_2026-07.md) | **Single-agent chat bug audit** — past issues verified fixed; 7 confirmed live bugs (Tier-1 loop-trip crash, Copilot retry duplication, unbounded resumed-session context, relay truncation/ack holes) + fix plan | 🟢 audit complete |
 | [`generative_ui_2.md`](specs/generative_ui_2.md) | **Generative UI 2.0** — immersive HITL UI: surface(panel)/hitl(blocking) on emit_generative_ui, 11-template library (recipe/flight/train/form/optionPicker…), side-panel genUI tabs, scenario→element map | 🔄 Phase 1 shipped |

apps/services/action_broker/action_broker/broker.py

@@ -14,13 +14,16 @@
   registry. A real source-of-truth write happens ONLY inside a registered
   handler, and an action with no handler is REFUSED (never silently applied).
 
-Ships with **zero** handlers registered, so it cannot perform any real write yet
-— it is non-breaking and inert until handlers are wired in. Still pending
-(needs per-agent authority decisions + a queue table): persisting
-``needs_approval`` proposals to a ``pending_actions`` table (mirror
-``pending_commit``), the Control Plane approval binding, and routing the existing
-ClickUp/email writes through :func:`execute`. See FOUNDATION_BUILDOUT_CHECKLIST
-BO-1.
+This module itself registers nothing — handlers are wired in by the gateway at
+startup / import (five sites as of 2026-08-03: ClickUp task writes, workflow
+resume, WhatsApp broadcast, and two app-tool actions). It is therefore **live**,
+not inert: ``pending_actions`` persistence, the Control Plane approval binding
+(gateway ``routes/actions.py``) and the ClickUp task-write reroute all shipped
+2026-07-13. Remaining per FOUNDATION_BUILDOUT_CHECKLIST §BO-1: two gated ClickUp
+actions still have no handler (BO-1a), the queued-write ``sync_state`` marker is
+ignored (BO-1b), and email writes do not route through here at all (BO-1c).
+There is no Zoho write client anywhere in the repo, so the ``"zoho.email"``
+example below is illustrative, not a pointer to real code.
 """
 from __future__ import annotations
 

apps/services/gateway/gateway/routes/actions.py

@@ -13,10 +13,13 @@
 outward-write bodies — CRM/email content — so it is never anonymous-reachable).
 Approve/reject go through ``action_broker.approve``/``reject``, which fail
 CLOSED: a missing or non-pending row is never run, and a handler error marks the
-row ``failed``, not ``applied``. The broker ships with **zero** handlers, so
-until real ones are registered, ``approve`` returns a refusal ("no handler") —
-the queue is visible and auditable but still cannot perform any real write
-(non-negotiable #4 stays intact).
+row ``failed``, not ``applied``. Real handlers ARE registered (five sites as of
+2026-08-03 — ClickUp task writes, workflow resume, WhatsApp broadcast, two
+app-tool actions), so ``approve`` performs the real write for those actions.
+An action with no registered handler still gets a refusal ("no handler") and
+the row is marked ``failed`` — see FOUNDATION_BUILDOUT_CHECKLIST §BO-1a, where
+two gated ClickUp actions (``delete_task``/``archive_task``) hit exactly that
+branch today.
 """
 from __future__ import annotations
 

apps/services/gateway/gateway/routes/tasks/providers.py

@@ -97,9 +97,12 @@ def _broker_enforced(action: str) -> bool:
     so the broker only audits + chokepoints them. Set the env var to
     ``1``/``all``/``on`` to queue every write, or to a comma-list of action names
     to queue specific ones. This is the kill-switch — flip it without a redeploy
-    (env var + service restart). NOTE: the queue path needs a persistent handler
-    to execute on approval (a follow-up); until then, enforcing queues a write
-    but it won't run until that lands.
+    (env var + service restart). Persistent handlers ARE registered at startup
+    (``tasks/broker_handlers.py``), so an approved queued write really executes.
+    ⚠️ NOT for every gated action: this class gates SIX action names but only
+    four have handlers, so approving a queued ``clickup.delete_task`` or
+    ``clickup.archive_task`` is refused and the row is marked ``failed``. Do not
+    turn this on before FOUNDATION_BUILDOUT_CHECKLIST §BO-1a and §BO-1b land.
     """
     import os
 

packages/acb_skills/acb_skills/manifest.py

@@ -19,7 +19,11 @@
   :meth:`isolation_tier`, :meth:`resolve_tool_surface`) are the values the
   platform should compute from the manifest instead of from hardcoded names.
 
-**Nothing here is wired into the run path yet.**  It is deliberately
+**Partly wired: only** :meth:`AgentManifest.from_config` **and**
+:meth:`AgentManifest.instance_key` **are on the run path** (``executor.py``'s
+``_resolve_agent_instance`` and ``gateway/routes/workspace.py``'s
+``_agent_instance_for``); every other derived accessor still has zero production
+callers — see ``agent_architecture.md`` §12.1.  It is deliberately
 side-effect-free so ``tests/unit/test_agent_manifest.py`` can assert that the
 derived values match what the platform does today — which is what makes the
 later flip a provable no-op rather than a hopeful one.