# Building Precise applications and services **Authority:** normative development and migration workflow. **Maturity:** the local harness, lazy attachment, estate index, generated HTTP service, SDK, evals, floors, release qualification, Precise publication and binding-receipt adapters, neutral manifest-driven application Gateway, optional Campaign Improvement standing composition, deterministic app bundle, and application descriptor builder are built and tested. Generic customer-cloud workload execution and the private application lifecycle are live-proven in Boombox. A 2026-09-02 observation found the older Campaign Improvement staging revision `app_rev_4ac0c1d7` healthy with 20 transitions, 17 input schemas, and event booking armed. It predates the current neutral `math` child, default continuation workflows, and read-only Campaign workflow projection. The dedicated Product bucket and bucket-scoped runtime IAM passed their first live create-only conformance smoke on 2026-09-01, but the observed Gateway still uses its existing application-state handle. The exact Precise assignment-bound worker traversal, a rebuilt closure-bearing two-revision apply/promote/rollback proof, remote-service composition, and runtime schemas/generated clients remain open. Precise is the research and product engine. It develops differentiated methods, models, evidence standards, decision systems, and customer software, then proves their behavior through canonical cores, evals, ablations, floors, and observable failure cases. Boombox supplies the reusable operating and distribution primitives that let those products run first in Precise infrastructure, then in customer estates and downstream networks without transferring their meaning or ownership. This is the shortest path for a developer or agent to build a Precise product, add a service, or bring an existing application under Precise control without rewriting it. ## The shape ```text product UI / agent │ Product commands only ▼ tenant-bound always-on Precise Gateway │ harness: commands + state + evals + floors │ canonical domain core + mounted Product defaults │ injected host ports (Boombox, GCP, local adapter, or service-owned override) ``` The UI is not the product logic. The harness is not a second implementation. It exposes one canonical core through a discoverable, testable, ablatable contract. GCS is a durable Product-state host, not a process runtime. The same Gateway process may run locally, on Precise GCP, under a compatible Boombox application runtime, or elsewhere. Application code sees the same Product URL and never selects storage or cloud identity. When a Product cell participates in Decision Learning, its stable read object is a recomputed episode, not a mutable Call chain. The core preserves independently authoritative Outcome Map and Window records, observations, distinct typed analyses, optional Call opening, actual Action Exposure, derived Forecast Score, Learning Decision, restatements, and one create-only closure over their exact references and digests. The episode recomputes from the closure and those primaries. A UI, BFF, host Receipt, telemetry event, or closure cannot invent an analysis, score, exposure, or learning decision. Products that need only part of this cycle still use the harness without fabricating the rest. For a decision-bearing workflow, use this narrower route: ```text named Product read ───────────────────────────────────────────────┐ canonical Product core → Decision Learning → Precise publication adapter ↓ │ thin BFF → UI / agent / MCP │ ↓ neutral host primitive port local / Boombox adapter ``` Decision Learning is the only Product judgment authority. The Precise publication adapter owns the mapping from exact Product records into opaque bindings and never recomputes the decision. The BFF joins current Product reads with that unchanged result and projects customer language; the UI and MCP surface do not import a decision core or receipt store. Change Product meaning once in the core, extend the Product adapter only when a new exact record must be mapped, and keep identity, custody, and effects in neutral ports at the composition root. The current public receipt contract plus local file adapter is not hosted custody, a deployment, application/workload run identity, attestation, calibration claim, or permission to act. The default developer contract has two tracks: 1. **Build a Product application.** Consume the tenant-bound Gateway client and its Product-shaped commands. Keep auth, custody, cloud credentials, and raw run controls at the server composition boundary rather than in the browser. 2. **Add a reusable capability.** Define or extend the Precise port, wrap the canonical core once, and add conformance plus useful/failure evidence. Replace a mounted implementation behind the port; never reimplement its meaning in the app. The owner composition supplies real defaults: calibration, the initial learning target and rights label, and descriptive contribution. Synthetic and customer data use the same source adapters and canonical records. A worked application is optional source material, not an assignment or the generic Product shape. ### Choose the method, workflow, or Product surface Use the narrowest public surface that matches the caller: - Call `math` directly when you are building a workflow, running research, or integrating a new vertical that needs one named method and the literal result. - Call `workflow` when several methods, their dependencies, comparisons, and later outcome cycles belong together. The current names are `understand-the-book`, `find-the-next-move`, `design-the-test`, and `measure-and-learn`; `focus` builds a one-cycle subset. - Call a Product BFF when the caller needs a Campaign Board, Trust evaluation, Goal, report, action, or other Product answer. A complete workflow-backed BFF compiles Product records into workflow inputs and projects raw results back into Product language. Campaign Improvement's current `/trust` adapter is a read-only modeled-example projection; it does neither of those jobs and does not execute a workflow. Builders choose among these layers. A Product surface asks for source connections, one accepted field map, and the measured goal. Its harness selects and composes the fitting workflows, runs method comparisons, and reruns them as data changes while the last complete answer remains visible. Technical workflow IDs, methods, and runs belong in why/what-changed drill-down. Project the answer at the finest supported controllable grain rather than one aggregate blob. Where the source permits, use dimensions such as creative × channel × audience × placement. Each primitive needs measured contribution, uncertainty, interactions, current size, and marginal value so it can load into a proposed move. Preserve unsupported dimensions as missing and distinguish a measured decomposition from a causal effect. Calls, actions, and outcomes stay in Product records. Do not copy a math implementation into a Product adapter. Do not expose all of a named workflow merely because one Product moment needs one method. Do not treat a workflow record as the Product's decision, exposure, outcome, or lesson. The workflow engine retains complete inputs, outputs, run references, outcomes, and pending/completed cycles. Across cycles it replays the original input plus outcome patches; it does not maintain a hidden mutable primitive model. If a method needs an evolving model, make the model bytes or content-addressed state reference an explicit part of the Product-to-workflow contract. ## Create a blank application From the repository root: ```bash npm run precise:app:new -- --slug app-name node scripts/precise-install.mjs app-name # then follow the emitted packages/app-name/README.md ``` The blank scaffold starts with `boombox.jobs` empty. Add a packaged Boombox job when the app has one. ## Start with live discovery From the repository root: ```bash node scripts/precise-install.mjs --harness-only cd harness npm run doctor npm run precise -- start npm run precise -- estate coverage npm run precise -- estate drift npm run precise -- estate gaps --code harness-missing ``` `npm run doctor` is local-only. The environment, Node runtime, and exact SDK pin are blocking; the optional repository-local Python analytics bridge reports its own `bridge_ready` status and is required only for work that invokes it. Bare `npm run precise` is the full machine tree, not a human quickstart; ask for one subtree when you need it. Then search before adding another abstraction: ```bash cd .. ccc search "where campaign allocation decisions are made" ccc search --path 'packages/**' --lang typescript "tenant identity binding" ccc grep 'defineHarness(\X)' harness --lang typescript rg -n "exactSymbolOrContract" . ``` Use the sources in this order: 1. `start`: the small product model and first proof. 2. a targeted `describe`: connected command, state, eval, and floor contracts. 3. `estate`: ownership, source location, maturity, deployment observations, and gaps. 4. CocoIndex: conceptual discovery across code and documentation. 5. `ccc grep`: structural patterns. 6. `rg`: exact call sites and final verification. CocoIndex is not proof that code is connected or deployed. Its shared scope is `.cocoindex_code/settings.yml`; run `ccc index` after meaningful code or documentation changes. ## Package the optional Campaign Improvement reference app This path packages the optional Campaign Improvement reference-app standing composition (B), not the generic Gateway. The neutral application Gateway (A) is `startAppGateway` over a `precise.app/v1` manifest (blank means no mount) on the `@precise/harness/always-on-precise-gateway` core with injected children. Run A from its generated package with `npm --prefix packages/ run gateway`; `harness/test/app-gateway-separation.test.ts` proves it starts without B. The blank road needs no Dockerfile. From the repository root, package A with: ```bash npm run precise:app:bundle -- --slug ``` That command emits a deterministic three-file app archive and an unsigned ConnectorBundle. Its JSON result names the archive, digest, connector, entrypoint, and `/harness/healthz`; signing, apply, and hosting remain outside the application-developer lane. An application developer does not package B. Precise produces the artifact once; a Boombox operator signs and applies it for the tenant. From `harness/`: ```bash npm run build:gateway-bundle npm run test:gateway-bundle ``` The B build prints the exact archive path, ConnectorBundle path, media type, byte count, and SHA-256 digest. The archive is deterministic and contains one `dist/server.mjs` entrypoint. The adjacent ConnectorBundle is deliberately unsigned and declares `precise_gateway`, tenant `precise`, `/health` on port 8787, and no tools. Precise never accepts a signing key or emits a signature. The test is a black-box host rehearsal: it extracts the archive, starts the actual bundled process, verifies `/health` and `/harness`, runs recommendation through mature outcome and learned closure, checks history, restarts, and requires exact state reattachment. This is the pre-sign acceptance proof, not a Deployment. For an owner-operated source checkout of B, setting the complete `PRECISE_GATEWAY_GCS_BUCKET` + `PRECISE_GATEWAY_GCS_PREFIX` pair before `npm run precise:app-gateway:serve` starts the reference app and selects its injected GCS composition. This GCS custody pair applies to B today. Ambient ADC/workload identity belongs to the process host. A partial pair refuses startup, and no bucket name, credential, or provider client enters an application route. The effect-free Boombox bundle remains independently useful; running it with GCS requires a host placement that explicitly supplies the corresponding storage identity. After the platform signing lane returns content-addressed signed-manifest and attestation references, import `defineStandingPreciseGatewayApplication` from `@precise/harness/standing-precise-gateway-application`. The builder uses the released Boombox descriptor validator, refuses a manifest bound to different artifact bytes, declares a harness-only surface, and declares no external intents, secrets, data handles, connector grants, frontend, or MCP path. The operator then owns sign/apply/provision and returns platform-issued Deployment and revision references; the application developer still does none of this. Operation continuity follows a separate contract. In hosted mode the Gateway uses the exact package-pinned published helpers to mint a `boombox.app-operation.v1` for each completed descriptor-declared operation and calls the tenant-authenticated host route with the injected `bopt_` credential. The host writes the platform store. `product_session_ref` is the opaque Precise episode ref; `outcome` is only the host operation fact; the host-emitted application revision record is the evaluation join; none of these is a Product judgment or `run_ref`. Precise seals that joined evaluation in its local application store and verifies it offline. Precise does not deliver the joined evaluation to Boombox; platform evaluation delivery is a later host seam. ## Choose the right seam A capability earns a harness when it has at least two meaningful variants to ablate or enforces a floor. Plain parsing, formatting, framework glue, and presentation components remain plain code. Use the default tree only when the capability is dependency-light and belongs in every Precise process. Use a lazy attachment when it is domain-specific, tenant-specific, dependency-heavy, separately deployed, or has its own authority boundary. An optional attachment also needs an estate entry and its own CI lane. ## Decide whether this changes a result Skip this section for ordinary presentation, transport, and plumbing work. The research protocol becomes mandatory when a change affects a product result, claim, model, prompt, policy, allocation, or promotion decision; it is not the entry fee for shipping a harmless screen or transport adapter. If the work compares or changes a model, strategy, prompt, data treatment, policy, allocation rule, or other result-producing seam, read `AGENT-ABLATION-RUNBOOK.md` before computing. Freeze the hypothesis, baseline, challengers, controls, outcome and unit, population, known-at cutoff, split or holdout, costs, capacity assumptions, floors, and promotion rule. Give every alternative a complete recipe assignment; the experiment kernel derives the changed seams rather than trusting caller labels. Use `createResearchProgramHarness` for the public `freeze`, `run_once`, `verify`, and `compare` commands. A component's local `ablate` command compares its invariant fixtures; it is not by itself an evidence-bound experiment or permission to promote a variant. Start with `cd harness && npm run precise -- research`. That default, domain-neutral node exposes the frozen protocol and pure verifiers to agents without loading a project adapter. It has no activation verb. Mount the runnable harness returned by `createResearchProgramHarness({ adapter, host })` only after the application supplies real evidence and provider ports. Use a durable result/ledger host for work whose receipt must survive the process. When the question is which evidence to acquire for one or more downstream decisions, use the `decision-program` child. Freeze a v2 decision map, a primary vector-budget plan, and then an independent hold-frame audit. Join selected work through experiment intent and `ResearchRoundAssignment/v1`; open and close its decision-impact episode so later planners see the full denominator and explicit training refusals. The cold exact coverage planner is a small-case reference. Its weights are declared decision criticality, not EVSI. An assignment still needs a separate signed Boombox admission receipt before any host resource or logical run may exist. After exact primary and sampled-audit outcomes exist, call `freeze-contextual-nomination` with distinct selector-withheld fresh support. Verify the receipt against the same v2 map, primary plan, audit projection, design, and receipt. It returns nomination-only authority or a sealed refusal; it cannot promote a candidate. For each contextually nominated scientific definition, pass the verified nomination to `freeze-contextual-confirmation-round`. Supply one new known-at offer per nominated definition, a covering planner identity, and the exact resource vector. The receipt projects only nominated definitions onto the bound fresh support, retains the full discovery denominator, and schedules every runnable nomination or refuses. Keep that outer receipt: the nested v2 map alone cannot become a confirmation assignment basis and grants no host or run authority. It remains planning-only and does not acquire fresh evidence or admit work. To assign a confirmation row, freeze the exact confirmation intent/spec and policy semantics, then call `freeze-confirmation-assignment-basis` with the outer receipt and its replay context. The basis binds the discovery, nomination, fresh-support scope, confirmation map, expected plan, and nominated definition into the physical evidence refs; an ordinary discovery basis cannot substitute for it. Separately, after a pinned domain verifier has validated its source receipts and issued target-scoped qualification, `project-decision-proposals` can account for one `move|adapt|fork|pin|ask|suspend|refuse` proposal per target. `move`, `adapt`, or `fork` needs an already-issued promotion-equivalent qualification bound to its exact tenant, predicate, workflow, decision contract, option, and validity window. `pin` preserves the exact incumbent; `suspend` explicitly stops it; and `ask` carries an interim pin-or-suspend policy plus nomination-only or promotion-equivalent qualification. Coupled portfolios refuse and remain an Arranger planning problem. These controls bind referenced terminal, court, fresh-support, and qualification receipts. They do not dereference and independently verify the pinned source bytes. A production composition must inject those source verifiers before treating a reference as scientific evidence or promotion-equivalent qualification. Ordinary plumbing and presentation changes do not need an experiment. Result-changing work does. Before a real-scale materialization or ablation starts, freeze its physical contract with `precise research freeze-physical-plan`. Name every create-only stage and dependency, bind the immutable release and evidence, put scratch on a separate non-nested mutable resource, seal both the engine resource settings and host ceilings, retain one complete denominator and common opportunity key, and keep information value separate from execution value. Include the resulting `plan_hash` in the workload evidence refs. This prevents a query shape, temp directory, heap limit, silent cap, or model-specific row drop from changing the experiment outside its scientific spec. When a policy chooses an action target or has entry delays/horizons, first run `precise research freeze-policy-semantics`. Declare whether the target is fixed before the policy or selected inside it, and give every variant its score target and evaluated action target. Direct calibration requires the same start offset, horizon, and payoff. Include the `semantics_hash` in the physical-plan evidence refs and run `verify-physical-policy-binding`; an intentional mismatch is an `exploratory-proxy`, not a directly calibrated candidate. Before dispatch, call `precise research verify-physical-workload-binding` with both seals. A workload that merely resembles the plan, changes tenant/run/ implementation identity, or omits the exact `plan_hash` is refused. Use `mutable_scratch_kind: "host-managed"` for a VM or container filesystem and record a positive `minimum_free_scratch_bytes` floor checked by the worker. Use `"provider-managed"` for BigQuery or another service whose scratch filesystem is not exposed, and set that floor to `null`. The distinction is evidence: do not claim a local disk measurement the provider does not expose. ## Run long work through the generic host Do not make a terminal, VM, agent session, or in-memory map authoritative for a backfill, capture, ablation grid, or other restartable job. Freeze its exact task universe with `freezeResearchWorkloadProgram()`, then compose the same worker against one of these ports: - memory for unit tests; - compressed file storage for local durable runs; - injected GCS storage for ADC/workload-identity cloud runs. Use `createResearchWorkloadRuntime()` from the Harness. `runCycle()` claims all due tasks, bounds simultaneous handlers with `concurrency`, exposes `renew()` and `checkpoint()`, fences stale workers, receipts retries, and commits one content-addressed terminal result per task. Domain code owns task bodies and artifacts; the host owns lifecycle. Never put raw payloads in progress facts or telemetry. For the first experiment-shaped task seam, use `createAdmittedResearchExperimentWorkloadBridge()`. Supply one contextually verified assignment, the exact runnable research harness, and an injected verifier for an already-issued host admission receipt. The bridge validates the assignment/workload/physical-plan/task/placement join before exposing a handler, then invokes the real `run_once` and stored `verify` path. It deliberately supports one task and cannot issue admission, dispatch, create resources, activate, or order. Boombox remains responsible for the authenticated signed receipt and the surrounding run/attempt/resource lifecycle. After the domain's canonical verifier freezes a terminal envelope, use `publishImmutableCurrent()` from the portable `@precise/harness` SDK (implemented by `@precise/research-core/publication`). It writes the immutable body and advances one logical current pointer by compare-and-set. An identical concurrent writer reattaches; a different result for the same logical pointer refuses. Publication does not imply acceptance, promotion, or permission to delete an upstream artifact. For a partitioned multi-stage program, freeze the complete partition universe before dispatch and bind one physical plan and workload per execution lane. Admit a downstream partition only from the exact verified terminal receipt for that same upstream partition. Keep worker concurrency separate from the frozen population: `concurrency: 4` means four simultaneous handlers, never “evaluate four partitions.” Declare placement and data residency per lane. Treat cleanup as its own destructive capability after an exact acceptance receipt, not as a success callback. The generic physical-plan, workload, and immutable-current primitives support this pattern now. The reusable cross-lane production-graph, placement, and acceptance-to-cleanup contracts are not yet a default Harness schema; the Polymarket actor-history adapter is the proved reference composition. Do not copy its domain terms into a media product or claim a generic orchestrator exists until that contract is extracted and conformance-tested. For a Boombox deployment, keep this program/state/receipt grammar intact. Boombox adds registry, triggers, compute reconciliation, identity, operator views, and retention; it does not reinterpret the experiment. ## Build one vertical slice Work one observable behavior at a time. For the first customer-shaped proof, make the slice small enough to show in one meeting: one existing named behavior, one deterministic customer-safe data source, one visible useful result, one genuine refusal, and one frontend consuming the same Gateway contract. Use the repository's already-attached Boombox Project; do not initialize a replacement Project or make the developer operate a primitive machine. Hosting is an owner/platform concern. A local Product composition proves the product path; it is not a hosted claim, and a green provider-free plan is not a Deployment or Run. ### 1. Name the public behavior Write the caller-visible contract in domain language. Include the useful result and the honest refusal. Decide which input and output require runtime validation and which host dependencies must be injected. ### 2. Add the failing test Test the canonical public interface, not an internal call sequence. A behavioral change begins red: ```ts test("decision refuses when executable inventory is absent", () => { assert.throws( () => buildDecision({ inventory: [] }), /campaign-decision-needs-executable-inputs/, ); }); ``` Use deterministic fixtures. Mock only remote systems, clocks, randomness, filesystems, or durable stores. Prefer a real lightweight adapter when possible. ### 3. Implement the smallest pure core Accept dependencies instead of constructing them. Return an explicit result or typed refusal instead of hiding a side effect or using `NaN`, `null`, or log text as policy. ### 4. Wrap the core once Expose the imported core through `defineHarness`. Add: - a stable name, purpose, version, and command; - a concise input-to-output contract; - cheap state that is honest about what is observed; - a success eval that checks a meaningful domain property; - an eval that actually exercises every declared floor. Tests prove software behavior. Harness evals prove domain quality, invariants, floors, and variant performance. Neither replaces the other. A hard-coded `pass: true` is not an eval. ### 5. Attach it For a universal capability, add it to `harness/examples/precise.tree.ts` and run the root eval. For an optional service, use the descriptor plus dynamic-loader pattern in `ATTACHING-HARNESS-SERVICES.md`, register one canonical ID in the lazy registry and estate catalog, and retain short names only as aliases. Do not import a heavy optional runtime from the default barrel or tree merely to list it. ### 6. Transport the same contract Use `startHarnessService()` for HTTP rather than writing a parallel API. Bind tenant identity from authenticated transport context; never trust a caller-supplied tenant path. Put host adapters at this composition root. When a command is exposed over CLI or HTTP, add parity coverage for the behavior you claim equivalent: ```text direct core == harness command == CLI/HTTP envelope ``` The current generated HTTP description is a named JSON/prose contract. Do not call it a schema-validated typed client until runtime schemas and generation exist. Response consumers must require every documented field and validate its shape, but accept unknown additive fields at every object depth. This applies equally to server adapters, browser clients, MCP tools, SDKs, and harness-to-harness clients. Producer input schemas stay closed, and raw-data, credential, tenant, and custody checks still refuse unexpected material. ### 7. Connect the product surface to its canonical core Repoint one UI route, job, or agent tool to the harness contract. Keep rendering and interaction state in the product; keep decisions, scores, floors, mutations, and refusals in the core. Render refusals as first-class states. ### 8. Bind history and operational projection Every Product action retains its authoritative ID, record history, evidence references, and applicable rights label. Do not create a parallel developer worklog or telemetry ledger for facts already present in those records. Boombox or another host may project payload-free operational state and indexes over them; the UI is not the sink and an operational projection cannot replace Product evidence. Never emit secrets, signer material, raw customer records, command arguments, or command outputs into telemetry. ### 9. Prove and widen Run the completion gate, update the estate and connection maturity, then move the next caller. Do not label a test-only wrapper as wired or a local reference adapter as production. ## Migrating an existing application Do not start with a rewrite. Use this ladder: 1. Add an estate descriptor for the package, service, job, deployment evidence, and known gap. 2. Find one consequential public behavior already implemented by the application. 3. Put a regression test around that behavior. 4. Import its canonical core behind a harness command; do not copy it. 5. Add real success and refusal/floor evals. 6. Attach it to the default tree or lazy registry according to dependency and authority boundaries. 7. Repoint one existing API route, UI action, scheduled job, or agent tool. 8. Add contract parity, evidence references, and payload-free telemetry. 9. Replace local reference adapters with live host adapters only after their guarantees are proven. 10. Repeat until the old entry path is only a client, then remove it deliberately. This can happen package by package and route by route. A remote harness client is still unbuilt, so an already-deployed service currently joins by wrapping its source core or by adding a local adapter; do not claim transparent federation yet. ## Suggested service layout ```text src/ core/ canonical domain behavior precise.harness.ts real imports, commands, state, evals, floors precise.surface.ts dependency-light lazy descriptor service.ts composition root: auth, tenant, host ports, telemetry test/ core.test.ts public behavior and refusals harness.test.ts eval/floor and direct-command parity service.test.ts HTTP envelope, auth, tenant, body limits ``` Do not create files that the seam does not need. A small universal capability may be one core file, one harness file, and one test. ## Completion gate Run the affected package tests first, then the shared lane when the harness, SDK, tree, or shared contract changed: ```bash cd harness npm run typecheck npm test npm run test:sdk npm run precise -- describe npm run precise -- eval ``` For an optional domain, also run its separate test and eval lane. Before completion: - success and refusal behavior are tested through public interfaces; - every declared floor is exercised by an eval; - result-changing comparisons have a frozen experiment spec, immutable evidence pointer, reproducible receipt, and explicit promotion or null decision; - direct, harness, and claimed transport behavior agree; - runtime input is validated at external boundaries; - estate metadata and `CONNECTIONS.md` match observed maturity; - docs contain runnable commands and name what remains unbuilt; - no secrets or customer payloads enter config, logs, topology, or telemetry; - `ccc index` has refreshed local discovery. ## Where to go next - `RUNBOOK.md`: exact local commands and deployment entrypoints. - `AGENT-ABLATION-RUNBOOK.md`: the domain-neutral experiment, ablation, receipt, and promotion protocol. - `DEVELOPING-HARNESSES.md`: ablation, floors, capture, and polyglot details. - `ATTACHING-HARNESS-SERVICES.md`: lazy registration and generated service pattern. - `PRECISE-ESTATE-BACKPLANE.md`: estate, topology, telemetry, and migration order. - `BOOMBOX-PLATFORM-CONTRACT.md`: host boundary and honest production gaps. - `BOOMBOX-WORKLOAD-CONTROL.md`: built Precise worker protocol plus the remaining Boombox control-plane contract. - `.claude/skills/precise-harness/SKILL.md`: the Precise agent operating law. - `.claude/skills/build-on-boombox/SKILL.md`: the exact package-pinned Boombox onboarding and build law. A Precise port defines what the product needs; it does not prove that the host already provides it. For platform operations, the packaged Boombox skill and executable CLI/MCP contract outrank prose.