Description
The point of SKT-0015 is that someone can point synthkit at a stack and exercise their high-DPM tooling. That needs a blueprint they can select, and it needs the cost stated somewhere they will read it BEFORE they select it, because this is the one blueprint in the catalogue that can cost real money by design.
Build a reference blueprint that opts in to the sub-60s cadence from SKT-0015.01 and declares a churn rate from SKT-0015.02. Keep the estate small — the target is high DPM per series and a turning-over series set, not a large estate. A user who wants volume can scale the estate themselves; a reference blueprint that is both fast and huge is a bill, not a demonstration.
Surface the projected cost at startup and in the control plane. The runner already knows the resolved instance count, each instance’s interval, and the per-blueprint series budget, so projected DPM is derivable rather than guessed. Log it at startup for any blueprint running below the default floor, and expose it where /control/ already reports blueprint state so the admin UI can show it. Do not make the operator compute it from the YAML.
Documentation: the blueprint’s own metadata.description, docs/blueprints.md, docs/configuration.md alongside the ceiling variable from SKT-0015.01, and docs/troubleshooting.md, which already warns about SERIES_CAP silently truncating and is exactly where someone will land when their numbers look wrong. Say plainly that SERIES_CAP is a per-push series backstop and the DPM ceiling is a per-series cadence bound — they are different controls and confusing them is the obvious mistake.
The blueprint must not enter the reality corpus or be treated as a fidelity reference. It models a deliberately over-scraped estate; the corpus records what real collectors emit.
Acceptance Criteria
- #1 A selectable reference blueprint runs at high DPM with churn, using only existing catalog constructs
- #2 Projected DPM and series count are logged at startup for any blueprint running below the default floor
- #3 Projected DPM is exposed through the control plane alongside existing blueprint state
- #4 The cost is stated in the blueprint metadata and in docs before a user selects it
- #5 Documentation distinguishes SERIES_CAP from the DPM ceiling explicitly
- #6 The blueprint is excluded from the reality corpus and from fidelity reference treatment
Definition of Done
- #1 make gate (build vet test race rw-proto-check spdx-check forbidden-words)
- #2 make blueprint-schema (only if a blueprint field or construct/workload config struct changed)
- #3 DRY_RUN=true go run ./cmd/synthkit -once -dump — inventory diffed against signals/
Implementation Plan
After SKT-0015.01 and .02 land, use the repository blueprint procedure to add a small selectable high-DPM/churn blueprint, derive projected DPM and series count for startup/control-plane display, and document cost plus the SERIES_CAP distinction before selection.
-
Add a small high-DPM network_topology blueprint using existing schema-backed catalog fields, with projected cost stated in metadata and no corpus registration.
-
TDD a projection derived from resolved metric-bearing instances, effective per-blueprint cadence, and series budget; log it at startup below the default floor and expose it in control-plane blueprint state.
-
Document the cost controls and SERIES_CAP distinction, run targeted inventory/schema checks, then complete the root-owned final integration gates.
Implementation Notes
Final evidence: high-dpm-churn validates at 115 exact series with a 690-point fixed-minute budget, 10s cadence and one edge replacement per minute. Startup logs project 115 series and 690 DPM; /control/schema and the admin UI expose the same projection. Go focused packages, 169 UI tests, UI build, schema generation, targeted dump and the integrated make gate passed. CodeRabbit final review completed with zero findings. Gate dispatch preflight confirmed gpt-5.6-terra/low with fork_turns=none; post-spawn model/effort metadata was unexposed by the client.
Final Summary
Shipped the selectable high-dpm-churn detector-test blueprint and made its 115-series, 690-DPM projected cost visible in metadata, startup logs, control schema, UI and operator docs. Kept it outside the reality corpus and explicitly separated SERIES_CAP from cadence controls.