Skip to content
ClearedStack

Platform · J.4 Component specifications

Shakedown specification

Design

Automated 5-condition verification worker that tests built static tools for offline execution, strict CSP, zero tracking, worked examples, and public citations before catalog publication.

J.4.143 min readLast revised November 2026

Status: Design. A specification. It describes how the component is meant to work, not something you can use on this site today. What the labels mean.

Registry entry · Stage 07

Checks a built tool against the five listing conditions before it can be listed.

Formerly
cs-07-verify
Namespace
cs-workers
Repository
shakedown
Container image
lazarette.clearedstack.svc.cluster.local:5000/shakedown
Depends on
Muster
Depended on by
Nothing else in the platform
Boundaries
  • Leases built tools from Muster
  • Returns a pass or fail on each of the five conditions

From the naming registry, which is the one place this component’s name is written down.

On this page
  1. Overview & Role
  2. Runtime & Resource Budget
  3. Interfaces & State Transitions
  4. Sub-Tools & Failure Modes
  5. Security & Clean-Room Boundaries
  6. Related pages

Overview & Role#

Shakedown is the automated quality-assurance worker in the cs-workers namespace (ownerRepo: Shakedown, version v0.1.0-draft). Split out of the original Stage 9 (List) design, its sole responsibility is to run the deterministic 5-condition verification suite against every static tool bundle built by Keelworks from a Moldloft repository.

Like every worker in the pipeline, Shakedown is a 100% deterministic Go service with zero AI at runtime. A tool cannot enter the live catalog unless every check in the suite passes.

Runtime & Resource Budget#

PropertyValue
Service / RepoShakedown (shakedown)
Namespacecs-workers
Kindworker (100% deterministic Go, zero runtime AI)
Versionv0.1.0-draft
RAM Budget30 MiB
Sub-ToolsNone ([] — universal 5-condition checks)
Local Spool/var/spool/cs (persists completed results across Muster restarts)
Contract VersionCONTRACT_VERSION=v1 (owned by clearedstack.com)

Shakedown runs under the Standard Kubernetes priority class so it yields cleanly if High-priority control-plane pods (Logbook, Muster, Conn, Plainforge, Lazarette, Shipkeeper) need memory on a 4 GiB k3s node.

Interfaces & State Transitions#

Shakedown never connects directly to Logbook or holds database credentials. It polls Muster over cluster-private HTTP using its Kubernetes ServiceAccount identity (lease, heartbeat, complete, fail, needs_subtool), always draining urgent before normal and normal before backfill.

  1. Input state (building): Picks up items whose static bundle has been generated by Moldloft and compiled without Docker by Keelworks (using rootless BuildKit).
  2. 5-condition verification suite:
    • Offline execution: Confirms the tool loads once and operates with the network disconnected, with all lookup tables, rates, and regulatory dates bundled inside the repository.
    • Strict Content Security Policy: Verifies connect-src 'self', default-src 'self', and form-action 'none' so the browser blocks any outbound data transfer or remote asset fetch.
    • Zero tracking or accounts: Confirms zero sign-in walls, analytics scripts, cookies, visitor counters, or third-party beacons, and verifies any local browser storage usage is disclosed with a clear-data control.
    • Worked-example assertions: Executes hand-calculated worked examples, boundary edge cases (zero values, empty inputs, date boundaries), and synthetic test fixtures.
    • Citations, scope limits, and MIT license: Checks that every calculation cites its official source (regulation, paragraph, revision date), states scope exclusions and a non-advice disclaimer, and includes an MIT LICENSE file.
  3. Output transition: Stages the signed verification result in /var/spool/cs and reports completion to Muster, hand-off ready for Chartroom to transition building → live. If regulatory ambiguity blocks verification, the item moves to parked.

Sub-Tools & Failure Modes#

Shakedown defines no per-case sub-tools (subTools: []) because the 5-condition verification suite is universal across all stack templates (calculator, checklist, validator, decision-tree).

Error CodeTriggerPipeline Behavior
E_PARSEMissing LICENSE, invalid CSP policy, failed worked-example assertion, or malformed bundleRefuses to guess; logs sanitized failure to Muster and halts item before catalog publication.
E_TIMEOUTStatic verification harness or fixture runner exceeds deadlineItem remains leased/retryable in Muster; Bellbuoy deduplicates repeated timeouts by fingerprint.
E_NEEDS_SUBTOOLUnrecognized bundle or assertion format introduced by a new templateFails closed, pauses item in needs_subtool, and triggers Bellbuoy to open a task; auto-replays once Shipkeeper deploys the fix.

Security & Clean-Room Boundaries#

  • Network isolation: Default-deny network policies block Shakedown from reaching Logbook, Plainforge, or Lazarette directly.
  • Unprivileged execution: Runs as non-root with dropped Linux capabilities, no privilege escalation, and a read-only root filesystem (apart from /var/spool/cs).
  • Clean-room & data hygiene: Verification fixtures must use synthetic or public data only; real CUI, proprietary contractor rates, and non-public solicitation text are strictly rejected. No raw Sextant observation artifacts ever cross into Shakedown.
  • Sanitized reporting: Shipkeeper strips internal IPs, node names, and pod hostnames before any failure status reaches pub.* or /platform/#registry.

Found a mistake, or something that has gone out of date? Open an issue or write to [email protected]. This page is a text file you can read and correct: Source of this page.