Generalizes working memory to a scope: ITeamMemory becomes IWorkingMemory with a
MemoryScope (Team | Product); MemoryEntry's TeamId becomes ScopeType+ScopeId (data-
preserving rename migration). On approval, Governance writes the decision/correction
at PRODUCT scope when the team belongs to a product (resolved via IBoardStats), so it
is shared by every agent across the product's teams — else at team scope. The assembler
recalls product memory (shared) plus team memory (local), merged by relevance, under a
"# Shared memory" section.
This is the other half of product-centric agents: a decision approved on one team now
informs every agent on the product, not just that team.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adds Product.Identity (a PRODUCT.md brief) and threads it through the run context:
AgentRunContextProvider resolves the run's team -> product and carries ProductId +
ProductIdentity on AgentRunContext; PromptAssembler injects a "# Product" section
(framed as shared, data-not-instructions) ahead of the agent's persona. Adds
GET/PUT /products/{id}/identity (read = view-board, set = owner) and the EF column.
This makes the product, not just the team, the unit of shared context — every agent
on a product sees the same identity. Product-scoped working memory follows next.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Autonomous agents with MCP tools now run a bounded tool-use loop: the model may
call tools (executed via the gateway, results fed back) until it returns a final
answer. Gated/DraftOnly agents get the tool catalog as data but never auto-call —
a human-in-the-loop agent never autonomously reaches an external tool.
Extends IModelClient with tool definitions and a tool-use conversation, adds the
OpenAI-compatible tool serialization/parsing plus a deterministic "tooluse" stub
client, and records every tool call in the run trace.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Reusable agent definitions authored as AGENTS.md (YAML frontmatter + a Markdown body that becomes
the agent's operating guide). Mirrors the skill library, including its review hardening.
- AgentProfile entity (OrgBoard): org-scoped + versioned by (OrganizationId, ProfileKey, Version),
NULLS NOT DISTINCT unique index; Origin Builtin|Authored|Installed; ProfileVisibility +
ProfileStatus with the Public⟹Published invariant enforced in Apply()/SetVisibility(). AGENTS.md
parser (YamlDotNet). AgentProfileWriter is the single upsert path (insert-only mode for install).
- Free builtins: AgentProfileSeeder seeds Aria (PO), Quill (QA), Edison (backend) on startup via a
new IStartupSeeder + SeederRunner (runs after migrations). Idempotent, null-org, visible to all.
- Endpoints (/api/orgboard/agent-profiles): upload, list (resolvable-winner order), get versions,
publish/unpublish, fork, marketplace (per-(key,version) AlreadyInLibrary), install (insert-only →
clean 409, no clobber). ConfigureAgents to author/manage; ViewBoard to browse; audited.
- Persona: Agent gains Persona; ConfigureAgent stores it; AgentRunContext carries it; PromptAssembler
injects it as "# Operating guide" (data, not instructions) so an applied profile shapes the run.
- Client: Agent profiles page (library + marketplace tabs, upload editor, publish/unlist/fork/install),
routed + in the nav.
Verified: ArchitectureTests 8/8, IntegrationTests 55/55 (new AgentProfilesTests: builtins seeded,
upload + validation, publish, cross-org marketplace list→install→private copy, duplicate 409, per-
version flag, Member 403; persona renders as the operating guide), client build green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Agents can now use Model Context Protocol servers. End to end:
- SharedKernel seam IMcpGateway (ListToolsAsync / CallToolAsync) + McpToolDescriptor / McpToolResult,
so the Assembler discovers and can invoke MCP tools without referencing Integrations' tables.
- Integrations: McpServerConfig (org-scoped, owner-only; auth headers AES-GCM encrypted, never
returned — only their names) + AddMcpServers migration. McpClient: a dependency-free Streamable-HTTP
JSON-RPC 2.0 client (initialize → notifications/initialized → tools/list / tools/call), carrying the
Mcp-Session-Id and parsing both application/json and text/event-stream replies. McpGateway resolves
an org's servers, decrypts headers server-side, and is best-effort: an unreachable server is logged
and skipped, never failing the run. CRUD + connectivity-test endpoints (create/test/delete owner-only
via ManageApiKeys; list via ConfigureAgents to bind).
- OrgBoard: Agent gains McpServerIds (uuid[]; migration backfills existing agents to empty) flowing
through ConfigureAgent + AgentRunContext.
- Assembler: AgentRunExecutor lists the agent's MCP tools (best-effort) and PromptAssembler renders a
"# Tools (MCP)" catalog — labelled as data, never instructions — and records it in the run trace.
- Client: SeatsPage gains an MCP servers card (add/test/delete, encrypted auth header) and a per-agent
MCP server multi-select; api client gains del().
Note: discovery + the governed call gateway are in place now; the autonomous model-driven tool-call
loop (model emits tool_calls → gated execution → feedback) needs a tool-calling model client and is
the next increment — the stub model can't drive it.
Verified: ArchitectureTests 8/8, IntegrationTests 53/53 (McpClientTests: JSON-RPC handshake/session,
json + SSE; McpServerRegistryTests: owner-only, encrypted-header-never-returned, graceful test,
Member 403; PromptAssemblerMcpTests: catalog + trace, omitted when empty), client build green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ISkillCatalog.GetByKeysAsync now takes the org id and resolves each key within that org's namespace
only — the org's own published skill, else a shared builtin (null org), never another org's. Org-owned
is preferred over the builtin; only Published (golden-tested) skills are injected; the resolved
skill@version is recorded in the prompt heading and run trace. AgentRunExecutor threads
context.OrganizationId. SeatsPage now loads the org library (builtins + authored + installed), dedupes
to one entry per key, and flags drafts (won't run until published).
Verified: ArchitectureTests 8/8, IntegrationTests 48/48 (new SkillRunScopingTests: a run assembles the
org's own skill over the builtin of the same key, and another org's same-key skill never leaks in),
client build green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Skills move from a global Git-only registry to a per-company library that orgs author and
version in-app — Git stays as the shared *starter* library.
Domain & persistence:
- Skill gains OrganizationId (null = shared builtin, visible to every org), Origin
(Builtin | Authored | Installed), AuthoredByMemberId. Identity is now
(OrganizationId, SkillKey, Version); the unique index uses NULLS NOT DISTINCT so builtins
stay unique by key+version while each org gets its own namespace (and can fork a builtin).
AddSkillOwnership migration backfills existing rows as Builtin.
- Owned GoldenExample rows are cloned in Skill.Index so a fork can't re-parent the source's
tracked entities.
Authoring (tenant, dynamic):
- POST /api/skills/authored — structured fields → same indexer pipeline (embedding +
publish gate apply identically), tagged org + author. POST /api/skills/{key}/fork copies a
builtin/global skill into your org as an editable Authored draft. List/Get are org-scoped
(your org + shared builtins). New Capability.ManageSkills (Owner + TeamOwner), audited.
- GET /api/skills/marketplace: read-only seam listing public skills across orgs (install is
the next step).
Security (from adversarial review — two confirmed criticals):
- Managing shared builtins is an operator action, not a tenant one. /index (posts arbitrary
content as a global builtin) and /sync (re-indexes the shared library) now require a
platform admin key (X-Skills-Admin-Key, fixed-time compare, fail-closed when unset) via
SkillAdminOptions — previously any authenticated user of any org could inject/poison global
skills. New test asserts an authenticated Owner without the key gets 403 on both.
UI: new /skills library page — browse shared + org skills grouped by key with their versions,
create / new-version / fork, golden-test editor + body, Draft/Published badge and the
publish-gate hint (needs roles + ≥1 golden test).
Verified: ArchitectureTests 8/8, IntegrationTests 46/46 (new SkillLibraryTests: org
isolation, version coexistence, fork, publish gate, Member 403, admin-gate 403), client build
green.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Working memory (Memory module's first real code):
- MemoryEntry (schema "memory", vector(384), InitialMemory migration); TeamMemory implements
the SharedKernel ITeamMemory seam (embed-and-store on write, cosine recall on read);
GET /api/memory/search. HashingTextEmbedder promoted to SharedKernel (pure, deterministic;
swapped for ONNX/BYOK embedders later behind ITextEmbedder).
- Written on approval: Governance's approve stores an Approval/Correction entry per decision.
- Read at assembly: the executor recalls the team's top-3 relevant entries; the prompt gains
a "# Team memory" section (treated as data, not instructions).
The single V1 event trigger:
- IAgentDispatcher (SharedKernel) implemented by Assembler's AgentRunDispatcher (shared by
the API and triggers). OrgBoard's QaHandoffTrigger: a task hitting done creates a QA task
(provenance parent, assigned to the QA agent) and dispatches a run for the team's QA AI
seat. Guardrails: Test/Review tasks never re-trigger (no self-cascade) and a task hands
off at most once. Audited as handoff.triggered.
Analytics — the V1 verdict view:
- IBoardStats (SharedKernel) implemented by OrgBoard; GET /api/governance/analytics returns
approval rate, avg edit distance, per-agent metrics + edit-distance trend, tasks done.
- UI: /analytics — stat cards, per-agent table, recharts edit-distance trend per agent.
Verified: build green; ArchitectureTests 8/8; IntegrationTests 42/42 incl. the M6 acceptance
end to end — a dev marks a story done → Quill wakes via the handoff (QA task with provenance,
assigned to the agent) → drafts a test plan that waits in review → approve records the second
agent's edit distance → analytics show approval rate 100%, avg edit distance > 0, and trends
for BOTH Aria and Quill; memory written on Aria's corrected approval is recalled into her next
prompt; the guardrails hold. Client build green.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
SharedKernel:
- ActionRisk (risk lives on the action) + GatePolicy (the pure autonomy x risk matrix:
Read never holds, Draft/Publish hold unless Autonomous, Destructive ALWAYS holds).
- IActionGate (AgentActionProposal -> execute|hold) and IBoardWriter.AttachArtifactAsync.
Governance:
- ReviewItem (held action: artifact, child titles, trace, decision, edit distance) in a new
review_items table (AddReviewItems migration).
- ActionGate: hold -> ReviewItem + "action.held" audit; autonomous -> execute + audit.
- HeldActionExecutor: writes the artifact onto the task and creates the child tasks via
IBoardWriter (implemented by OrgBoard — no cross-module table access).
- Review inbox API: GET /api/governance/reviews (scope-filtered to where the caller may
approve), POST /reviews/{id}/approve (optional edited content/children -> normalized
edit distance recorded — the north-star metric), POST /reviews/{id}/sendback. Deciding
twice is 409; Members are 403.
Assembler:
- OutputParser (numbered-list child titles, conservative) and the executor now hands every
completed run's proposal to the gate.
OrgBoard: WorkItem.AttachArtifact + BoardWriter.AttachArtifactAsync.
Verified: build green; ArchitectureTests 8/8; IntegrationTests 41/41 incl. the full M5
acceptance — Aria (gated) proposes a spec, it waits in the inbox with its trace, a Member is
403'd, the owner edits-and-approves, the spec + four child stories land on the board, edit
distance > 0 is recorded and audited; Quill (autonomous) executes straight to the board;
destructive holds even for an autonomous seat and can be sent back. Plus the GatePolicy matrix.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
SharedKernel contracts (so Assembler stays decoupled): IAgentRunContextProvider (agent +
task) and ISkillCatalog (skill prompts by key). Implemented by OrgBoard (AgentRunContextProvider)
and Skills (SkillCatalog).
Assembler:
- PromptAssembler builds house-style + identity + the agent's skill bodies + the task, and
derives the primary action + risk from the agent's first skill. RAG/working-memory join at M6.
- AgentRunExecutor (real): resolve context + skills → assemble → resolve BYOK config (with
fallback) → call IModelClient → parse into action + risk → capture all on the AgentRun.
Verified: build green; ArchitectureTests 8/8; IntegrationTests 29/29 — incl. the M4 acceptance:
assigning a Spec task to Aria (PO, gated, stub BYOK) yields a Completed run with the assembled
prompt (skill body + task title), action "write-spec", risk "Draft", and model output. Nothing
executes — the gate is M5.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
SharedKernel: IWorkerModule seam (RegisterWorker runs in the worker host only).
Bootstrap: AddTeamUpWorkerServices; the worker host now wires it.
Assembler module (schema "assembler", InitialAssembler migration):
- Job (Pending→Processing→Done/Failed) + AgentRun (Queued→Running→Completed/Failed) entities.
- JobQueue: enqueue + ClaimNextAsync using `FOR UPDATE SKIP LOCKED` in a transaction.
- AgentRunExecutor (Increment-1 placeholder — real assemble/model/parse lands in Increment 2).
- JobProcessor BackgroundService drains the queue on the worker host (web off the model path).
- POST /api/assembler/runs enqueues a run; GET /api/assembler/runs/{id} reads it.
Verified: build green; ArchitectureTests 8/8 (Assembler references only SharedKernel);
IntegrationTests 28/28 incl. enqueue→claim(SKIP LOCKED)→process→Completed.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
SharedKernel: Autonomy dial enum; IModelClient (ModelRequest/ModelCompletion);
IApiConfigResolver (+ ApiConfigSummary/ResolvedApiConfig) — server-side, decrypted.
Integrations module:
- ApiConfig entity (org-scoped) + IntegrationsDbContext (schema "integrations") +
InitialIntegrations migration; the key is AES-256-GCM encrypted at rest (key derived from
Encryption:MasterKey) and never returned to a client.
- Model adapters: StubModelClient (no-network, provider "stub"/"echo"), an OpenAI-compatible
HTTP adapter, and a ModelClientRouter; ApiConfigResolver decrypts server-side only.
- Endpoints: POST/GET/DELETE /api/integrations/api-configs and POST .../{id}/test. Create/
test/delete require ManageApiKeys (owner); listing requires ConfigureAgents (assign-only,
no key). Dev master key in appsettings; override Encryption__MasterKey in prod.
Verified: build green; ArchitectureTests 8/8 (Integrations references only SharedKernel);
IntegrationTests 26/26 incl. a BYOK flow — key never appears in any response, the connection
test succeeds (stub), and a Member is 403'd from create + list.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Author the four V1 skill atoms in skills/ (Git is the source of truth): spec-writing &
story-breakdown (product-owner), test-plan-generation & diff-review (qa) — each with
risk-tagged actions, golden tests, and a body.
- SharedKernel: IGitProvider seam (read-only, provider-agnostic) + GitFile.
- Integrations module (its first real code): FileSystemGitProvider (dogfood/local) and a
GiteaGitProvider (Gitea REST: recursive tree → SKILL.md blobs → base64 contents); the
provider is chosen by GitSource:Provider config.
- Skills: SkillSyncService consumes IGitProvider (never Integrations) and indexes each file;
POST /api/skills/sync and a POST /api/skills/webhook/gitea (re-sync on push; signature
verification + changed-file-only + queue offload come later).
Verified: build green; ArchitectureTests 8/8 (Skills & Integrations reference only
SharedKernel; the Git seam lives in SharedKernel); IntegrationTests 22/22 incl. a sync that
indexes the four real atoms from skills/, published and queryable by role.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adds the access foundation everything else enforces against.
SharedKernel (shared access contracts, no Identity dependency for consumers):
- ScopeRef/ScopeType, RoleType, Capability, AccessPolicy (role x capability matrix),
ICurrentUser, IPermissionService (scope-chain evaluation).
Identity module:
- Member, Membership, Invitation entities; internal IdentityDbContext (schema
"identity") + InitialIdentity migration; design-time factory.
- JWT auth (HS256) issuing membership claims; PasswordHasher<Member>; CurrentUser
(claims -> ICurrentUser) and PermissionService implementations.
- Public IMemberDirectory contract for other modules to resolve member display info.
- Endpoints: POST /bootstrap (first owner), /auth/login, GET /me, POST /invitations,
POST /invitations/accept. Owner-only actions enforced via IPermissionService.
- Web host wires UseAuthentication/UseAuthorization and string-enum JSON.
Verified: build green; ArchitectureTests 8/8 (Identity references only SharedKernel);
IntegrationTests 11/11 incl. a new end-to-end flow — bootstrap -> login -> /me ->
invite -> accept -> login as invitee, and a Member is 403'd from inviting.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Stand up the modular-monolith skeleton per docs/V1_BUILD_PLAN.md: one .NET 10
solution with web + worker hosts sharing seven interface-bounded module projects,
PostgreSQL 17 + pgvector via EF Core 10, a React 19 + Vite SPA built into wwwroot,
and Docker Compose for one-command local dev. Skeleton only — no feature code.
Architecture
- One project per module (OrgBoard, Identity, Skills, Assembler, Governance,
Memory, Integrations); each is its own assembly so non-public types (entities,
DbContext) are invisible across modules at compile time.
- TeamUp.Bootstrap is the only library that references all modules; both hosts
reference only Bootstrap. SharedKernel/Infrastructure never reference modules.
- IModule seam: Register(...) runs in both hosts; MapEndpoints(...) only in web.
- PlatformDbContext owns the pgvector extension + the seven module schemas
(InitialPlatform migration); MigrationRunner applies it then any module context.
- One image, two roles selected by RUN_MODE at the Docker entrypoint.
Verified
- dotnet build green (nullable + warnings-as-errors).
- ArchitectureTests 8/8 — reflection-based boundary rules (no module -> module,
-> Infrastructure, -> Bootstrap, or -> host references).
- IntegrationTests 10/10 — Testcontainers boots the host against real pgvector:
migration applies, vector extension + 7 schemas exist, /health 200, every
/api/<module>/ping 200, /openapi/v1.json served.
- client builds clean (Vite 6 — pinned for Node 22.3.0; Vite 8 needs Node >=22.12).
Packages and base images route through the Nexus mirror (mirror.soroushasadi.com),
reachable from Iran when nuget.org / Docker Hub / MCR are not. CI is intentionally
deferred to a later session.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
soroush.asadi