01-projects/phdata

Hex deployment matrix v2 — refreshed against the 7/05-06 brigade-house consolidation

2026-07-07·project·status: draft-for-founder
phdataagent-brigadecafhexagonal-architecturedeployment

Hex deployment matrix v2 — what the consolidation proved, and the three open calls

Amends [[2026-07-03-hex-deployment-matrix]] (founder go 2026-07-07 morning). v1 remains the reference for the full adapter tables and composition rules; this doc is the operative delta + the answers to v1's three open questions, grounded in [[2026-07-07-brigade-house-handoff-review]] and the bundle's HANDOFF-DECISION-TRACE.md. Passed a zero-context adversarial review; overclaims it caught are corrected below.

What changed under the matrix (7/05-06, verified in the handoff review)

v1 assumption Now
Five separate workspaces; packaging = one plugin (skill-agent-brigade) ONE marketplace repo, 7 plugins — 5 on the ab- scheme (4 brigades + ab-registrar) plus copilot-studio-agent-builder and snowflake-cli. ab-website is deliberately NOT a marketplace plugin — it rides the frontend repo because its artifact is commits there. Packaging pattern proven on ab-assessment; the other four marketplace installs are untested post-rename.
Steward = a skill inside the factory ab-registrar extracted — the FOH is its own plugin (house role: mise + read-only orders/registry verbs, no menu, no service loop). The intake seam now has a concrete home.
Shared filesystem rail = fragile (any walker can lease any ticket) rail_adapter 1.1.0 walker scope — multi-BRIGADE on one rail is safe (foreign tickets skipped untouched, regression-pinned to the live mis-pull incident). R4 unchanged for multi-WALKER: the filesystem lease is still advisory, one walker per brigade by convention.
Machine portability = hoped Engineered: machine-default paths deleted, $CELLAR_ROOT/$COMPANY_JOBS_DB fail-loud with named remedies, mise env-agreement checks in every brigade. The store legs of R1 are now mise-checked; Anthropic-API reachability remains a runtime concern mise doesn't cover.
Website = read-only consumer; Snowflake target = "SPCS container (built)" on paper The marketplace is DEPLOYED in Snowflake via App Runtime (sandbox KMB25927, from env-as-code: snowflake_deploy.py provision/deploy-proc/ingest/status + doctor + grants tiers). One caveat the review flagged: the trace's "Ben confirms live render" was never recorded done — deployed, render-confirmation outstanding. Plus a real WRITE-side seam: the assessment-publish lane (ingest --with-files + refresh; publish record in cellar; manifest commit IS the approval). Doctrine: content publish = ingest+refresh; snow app deploy = code only — the ~45min remote build is paid only for code.
C6 two-cellars risk Treated as resolved in the handoff review's bookkeeping: the 7/6 bundle's cellar is canonical going forward, mini copies historical. (Ray's call, founder can veto.)

R5 — multi-person sync (added 2026-07-07, founder ratified in dialogue): the rail and the cellar have opposite sync requirements — never solve them with one drive. File-sync services (GDrive/Dropbox/Obsidian Sync) are eventual-consistency with conflict-COPY semantics: on the RAIL they double-lease tickets, race the service lock, and silently fork build records — file-sync doesn't fail loudly, it forks quietly. So: rail never rides a sync drive; the moment a second operator works the same house, the rail moves to the Snowflake-table backend designed inside canon (real compare-and-set lease, org-native access). The CELLAR is append-mostly (supersedes = new files, not edits) and belongs in a private git repo — history, explicit merge, evidence-of-record semantics; sync drives at most as a read-only human mirror (agent I/O footguns: streaming placeholders, sync daemons vs secret hygiene). Bridge shape for two people before the Snowflake rail lands: partition rails per operator, share the git cellar — no shared hot state, no races. This converges with P3 (cellar → Snowflake stage for client-governed work) instead of adding a sync-drive detour that gets ripped out later. P2's row amends accordingly: rail = Snowflake table (not "Jira or filesystem+single-walker"), cellar = git.

Constraint made explicit (from the 7/3 session, frontend commit 0ab6449 "steward grounding-surfaces declaration + mise reachability check"): R1b — grounding reachability extends to the steward. Menus declare per-brigade grounding surfaces (ab-website grounds in its git repo); a steward runtime must reach the declared surface. Consequence for P4: a Cowork steward cannot serve a repo-grounded brigade unless that repo is reachable from its runtime.

Updated profile table (deltas only)

Profile Change
P0 Local dev Proven end-to-end on a real engagement twice (Lenovo 7/2, Novo Nordisk 7/6: intake → research → assessment → manifest → website → collateral, rail left empty).
P1 phData single-operator The unit of transfer is now the brigade-house bundle + deploy runbook (7/6), superseding the 7/3 zips. Port in flight as of this morning.
P2.5 Snowflake showcase (new) Steward + brigade local/headless · cellar filesystem canonical · publish lane ingests to Snowflake · website on App Runtime. Deployed on sandbox 7/6 (render confirm outstanding — step 0 below). The deployable-today shape that gets the website off localhost without gating on C1: the brigade never enters Snowflake, only its outputs do.
P3 Snowflake-native Website leg de-risked (App Runtime exercised; sharp edges documented: cwd-sensitive snow app deploy, injected SNOWFLAKE_* collision solved via MARKETPLACE_* precedence with a regression test, account must be App-Runtime-enabled, snow CLI ≥3.19). Brigade-in-SPCS remains unproven and C1-gated — P2.5 exists precisely so P3 isn't the only Snowflake story.
P4 Cowork sales org Refined by the re-org — see Q2.

The three open questions — answered

Q1: P2 rail — Jira/Linear vs filesystem?

Answer: split intake from rail. Jira becomes the registrar's INTAKE adapter; the rail stays canon filesystem. The 7/3 lean ("Jira for the rail + intake") predates two facts: (a) the rail semantics a Jira mapping must now carry grew — Gate A lint runs at BOTH enqueue and pull, work-logs are append-only, and close-out signatures are load-bearing (they're the idempotency marker for the steward sweep) — so C3's field-mapping surface is larger than v1's estimate; (b) ab-registrar exists, so the org-native surface has a home that never touches rail semantics: registrar reads the Jira queue → lints → enqueues canonical tickets on the house rail → the close-out sweep answers back to the Jira issue.

The honest cost of this shape (adversarial-review catch): it creates two ticket records — the Jira issue and the canonical rail ticket — that must stay consistent, which brushes against R2's one-store spirit. Why it's still the better trade: the consistency burden lives at ONE seam owned by one role (the registrar, whose close-out sweep already exists by contract), instead of Jira semantics leaking into every brigade's walk; the Jira side is a view (truth stays on the rail ticket, same doctrine as v1's C3 "Jira carries pointers"); and the mirror is severable — intake can start as a plain form that creates canonical tickets with no standing Jira mirror at all. If >1 concurrent walker per brigade ever becomes real, the escalation is the Snowflake-table rail already designed inside canon (real compare-and-set, client-governed), not Jira-as-rail. Since the 7/3 consolidation of the 3+ drifted rail implementations into one canon module, a new backend lands once and re-vendors everywhere — materially cheaper than when v1 was written.

Trigger definition (v1 left it vague): the Jira-intake spike fires when either (i) the first non-founder requester needs to hang work, or (ii) sales-backlog intake exceeds what founder-as-steward clears interactively in a sitting (~5+ requests/week sustained). Until then, filesystem + founder-as-registrar is the whole story.

Q2: Is P4 Cowork still the 60-seat target post-re-org?

The re-org strengthens the steward/brigade split rather than changing the surface. Per the 7/1 re-org announcement (Nick Haylund; recorded in local state, not in the two cited docs), the Tiger Team's charter is how phData activates Claude Cowork + Claude Code as repeatable, delivery-runnable capability — which is literally what the brigade factory produces. So P4's first real customer may be the Tiger Team itself rather than the sales org. For the 60 sales seats, the consumption surface that matters is the marketplace website + published collateral (both deployable in-Snowflake via P2.5) plus intake (Q1's registrar seam); very few seats ever need to operate a brigade. Refined P4: sales seats = intake + consumption only; steward-in-Cowork where R1b permits; the brigade loop stays headless — the decision trace records the founder's own production intent as one Claude Code session per brigade polling the rail (~30s loop). A live counter-read exists: if the AAI/FDE motion really replaced the 6/15 "Cowork-primary 60-seat" premise, the right move is deleting the P4 row, not refining it. That's a founder-confirm with AK/Tiger Team once the port lands — this is a read, not a ruling.

Q3: Which profile for the KB4 onsite (July 15)?

P1 for anything hands-on; P2.5 as the showpiece — via screenshot by default, live URL only if two gates clear. The workshop's live material rides local (zero external dependencies, proven, no client approvals). The "where this goes" narrative now has a concrete artifact: the marketplace running inside Snowflake on App Runtime. Honest framing (v1 said the AEs want the P3 story — brigade IN Snowflake): P2.5 is not that; it's the credible first step toward it, and it's real today, which beats a P3 slide that isn't. Gates before showing a live URL: (1) the render confirm on the existing sandbox deploy has never been recorded — do the 2-minute check first; (2) the deploy sits on the founder's personal sandbox — either clear that with Dom Rocco/Gary Duma or re-provision on a phData demo account. On (2): env-as-code makes re-provisioning a runbook run only if the target account has App Runtime enabled — it's public preview, the sandbox happened to be pre-configured, and enablement on a phData account may need admin action nobody in the room controls. Eight days out: if the live-URL version is wanted, start the account question this week; otherwise a screenshot of the sandbox render loses almost nothing (the founder's KB4 lane is narrative + architecture — Gary owns the demo; P2.5 is a slide, not a second demo).

Revised sequence

Step 0 (2 minutes, before anything): confirm the App Runtime render on the sandbox — the one unrecorded verification, and it gates both P2.5 claims and the KB4 showpiece. → Day-one git safety: both branches are unpushed; the zip is the only backup — get the repos a remote (phData Bitbucket) before building on them. → P1 port per runbook (fresh-install test for the four untested marketplace plugins is runbook step 1) → P2.5 account decision + re-provision on a phData-side account (KB4-deadline-relevant; verify App-Runtime enablement first) → registrar Jira-intake spike on the Q1 trigger → P3/P4 as client/GTM demands, C1 spike only when a client actually requires brigade-in-Snowflake.

Still open (honest)