Engineering, with the evidence labelled.

Operational models, in plain terms

• ServiceOPS: business-calendar SLA in business minutes, distinct from the wall-clock order SLA; explainable assignment naming the disqualifying constraint; deterministic greedy scheduling compared with a naive baseline; atomic commands with audit events.
• ProcureOS: safety stock, reorder point, and EOQ shown with formulas; seeded Monte Carlo stockout simulation; landed-cost quote comparison; role-gated approval state machine with typed confirmation over $100k.
• FreightFlow: Dijkstra routing with equipment rules and closures; carrier feasibility and weighted scoring with a decision trace; integer charge-level profitability; immutable scenarios versus executed recovery.
• EstimateOS: decimal-exact chain, direct to indirect to contingency to tax to fee, with markup (cost × (1+p)) kept distinct from margin (cost ÷ (1−p)); immutable revision snapshots; frozen-revision PDF proposals.
• ForgePlan: deterministic finite-capacity scheduling with invariant auditing; eight dispatch policies compared; CNC-outage recovery with lexicographic ranking and a consequence chain. Greedy heuristic; no optimality proof is claimed.
• PantryPal: one transactional inventory engine (applyCommand) shared by demo and real backends, with undo and audit; demo isolation verified in code at PR #9 head (sessionStorage only, demo-first provider, no-op event log).

Test evidence, honestly labelled

VW-100 reconnaissance was read-only and did not re-run any product test suite, so no product pass count is claimed as re-verified. What was observed is file inventory; what the repos claim is labelled DOC-CLAIMED. This harness's own registry tests are run in CI on every change (see below).

• ServiceOPS: 4 domain test files, 4 end-to-end specs (OBSERVED, file inventory). Pass count UNVERIFIED. No CI.
• ProcureOS: 3 unit files, 1 end-to-end spec (OBSERVED, file inventory). Pass count UNVERIFIED. No CI.
• FreightFlow: 14 unit test blocks counted in the domain test file (OBSERVED); 14 unit + 5 browser tests DOC-CLAIMED. CI workflow exists; no run results observed.
• EstimateOS: 25 engine test cases counted from file text (OBSERVED); none run. No CI, no results record.
• ForgePlan: 9 test files, 5 end-to-end specs (OBSERVED); 174 unit + 16/16 end-to-end DOC-CLAIMED at an earlier commit. Install outcome UNVERIFIED. No CI.
• PantryPal PR #9: 254 unit + 38 integration tests DOC-CLAIMED in simulated environment. None re-run. CI workflow exists at PR head; no run results observed.
• Worth: registry tests in this repo, run by the CI workflow added in this change. A demo launches only when status is ready and its https origin is allowlisted; the allowlist is currently empty.

Integration contracts

The full contract text lives in docs/INTEGRATION_CONTRACTS.md in this repo. The binding summary:

1. Launch (IC-1): link-out only, to a verified https origin on the Worth allowlist, with status ready. No iframe embedding: ServiceOPS, ForgePlan, and PantryPal forbid framing in their own headers, and EstimateOS framing needs a build-time origin. No demo is linked before its deploy is verified live.
2. Return (IC-2): every demo offers a visible way back to Worth, driven by a deploy-time portfolio-origin variable. None of the six evidences one today; adding it is a change request, not an assumption.
3. Sandbox identity (IC-3): no login, no shared auth, no shared storage keys, no cross-app state. Each app keeps its own key: ServiceOPS localStorage v2, ProcureOS localStorage v3 plus role, FreightFlow IndexedDB v1, EstimateOS localStorage, ForgePlan localStorage (origin-wide, not tab-isolated), PantryPal sessionStorage (tab-scoped).
4. Reset (IC-4): every demo exposes a reset that restores its deterministic seeded fixture without registration, and scenario work in ServiceOPS stays isolated from canonical state.
5. Fixtures (IC-5): fixture IDs stay stable across deploys so case-study copy and acceptance tests can reference them: WO-10483, MOT-4408 / PO-23995, Iron Relay, Northstar 12,842.37, CNC-02 outage, and the three PantryPal scenarios.
6. Presentation (IC-6): each app keeps its own operational character. Shared bars only: visible synthetic-data label on every view, responsive at 375px with no horizontal overflow, visible reset and exit, keyboard-reachable controls, and illegal transitions surfaced as feedback, never a blank screen.
7. Acceptance (IC-7): before any ready claim, the Worth owner verifies live: the URL responds, the hero fixture renders, the guided path completes, reset restores the seed, and no Worth page links to a private-repo URL as a visitor destination.
8. Hosting (IC-8): this harness is a static export. It deploys to any static host; no Vercel-specific config is required, and no Vercel connection is a precondition for building, testing, or reviewing this change.

Remaining launch blockers, ranked

• P0: No demo has a verified public deployment. Worth correctly links none. ForgePlan install outcome unverified; EstimateOS has no main branch; PantryPal demo is unmerged.
• P1: No return-to-portfolio link is evidenced in any demo. No CI in ServiceOPS, ProcureOS, EstimateOS, or ForgePlan. ForgePlan demo state is not tab-isolated.
• P2: Private-repo links in ServiceOPS and ProcureOS 404 for visitors. FreightFlow Works vs Worth branding undecided. Unmerged PR stacks in FreightFlow and ForgePlan.
• P3: Dual lockfiles in PantryPal PR #9. EstimateOS embed origin unset. Croston/SBA forecasting disclosed as not implemented in ProcureOS.

Change requests for the owning agents are in docs/CHANGE_REQUESTS.md. Nothing in this change edits a product repo.