Skip to content
ClearedStack

Section J · Attachments

Revised November 2026

Platform

How the project decides what to build, builds each tool from the public rule, and is designed to run. You do not need any of this to use a tool or read a guide. It is here so that anyone can check how decisions are made.

What is true today

  • This website is a folder of plain files. It has no server, database or API behind it, so nothing on it can show live cluster data.
  • 0 of 18 tools are live. A tool is marked live on the day it works and not before.
  • Every platform component is a draft. The versions recorded in the naming registry end in -draft.
  • Figures and buttons on these pages are samples. Status panels show example values, and the Edit button is a preview that sends nothing.

What the labels mean

Design
A specification. It describes how the component is meant to work, not something you can use on this site today.
Built
The code exists in its repository and passes its own tests. It is not yet serving this site.
Running
Deployed, and you can see it working.

A page moves up a label when the thing it describes does. The label is one line at the top of the page’s source file.

Showing 27 of 27 pages

J.1

How tools get made

The pipeline that finds an idea, scores it, credits it and builds it from the public rule.

5 pages · 28 min

  1. J.1.1How the project is put togetherDesignThe parts of the factory behind the catalog, the path from an idea to a listed tool, and the four rules everything else follows.5 min
  2. J.1.2The pipeline and its ten workersDesignWhat each of the ten workers does, why none of them uses AI, how a case no rule covers is handled, and how the workers stay in step.9 min
  3. J.1.3An item’s life: fourteen states and three lanesDesignEvery state an idea for a tool can be in, the moves between them that are not a straight line, and the three priority lanes that decide what is worked on first.4 min
  4. J.1.4How we decide what to buildDesignThe five knockout gates an idea has to pass, the 100-point rubric it is scored on, how ties are broken, and who makes the final decision.5 min
  5. J.1.5Clean room and creditDesignWhat is taken from an existing tool and what never is, how the wall between looking and building is kept, how ideas are credited, and how a vendor can ask for a correction.5 min

J.2

What it runs on

The cluster the pipeline is designed to run on, how the public proposes changes and how it is operated.

3 pages · 19 min

  1. J.2.1Cluster architectureDesignThe one-node, two-namespace cluster the pipeline is designed to run on: its seven control-plane services, how code is built and deployed without Docker, and where the data lives.7 min
  2. J.2.2Public edits and what stays privateDesignHow a reader is meant to propose a change without an account, the five checks that keep that safe, where each proposal goes, and the line between what the project shows and what it hides.5 min
  3. J.2.3Operating it: status views, failures and backupsDesignThe fixed rules that decide what a status page shows first, what happens when a worker fails, and how the three stores of data are backed up and tested.7 min

J.3

How it is governed

What has been decided, what is still open and how AI is used in the work.

2 pages · 7 min

  1. J.3.1What is decided and what is openThe choices behind the design and why each one was made, how a question gets settled, and the three questions that are still open.4 min
  2. J.3.2How AI is used to build this projectAI assistants help write the code and the guides, under one person’s review. No AI runs in any tool, and none is designed into the pipeline.3 min

J.4

Component specifications

One specification for each control-plane service and each pipeline worker: its job, its interfaces and how it fails.

17 pages · 46 min

  1. J.4.1Conn specificationDesignUnified Command Portal, App Store UI, and anonymous edit intake serving as the sole public Ingress in the clearedstack namespace.3 min
  2. J.4.2Muster specificationDesignCentral queue lease manager, state-transition gatekeeper, SSE live feed publisher, and 5-layer anti-spam edit intake in the clearedstack namespace.3 min
  3. J.4.3Logbook specificationDesignThe platform’s one record of state: the working records, the public views of them and the append-only ledger, kept today in a single PostgreSQL 17 database.2 min
  4. J.4.4Plainforge specificationDesignLightweight MIT-licensed Go Git server in the clearedstack namespace acting as cluster-primary source of truth with push-mirroring to GitHub.2 min
  5. J.4.5Lazarette specificationDesignInternal-only OCI v2 image store in the clearedstack namespace retaining the last 5 cosign-signed digests per app for instant rollback without Docker or GitHub image hosting.2 min
  6. J.4.6Keelworks specificationDesignNo-Docker build controller in the clearedstack namespace that spawns ephemeral ko and rootless BuildKit Jobs on push, runs golden tests, signs digests with cosign, and updates app.yaml.2 min
  7. J.4.7Shipkeeper specificationDesignApp-Store reconciler and live pod/error sanitizer in the clearedstack namespace that replaces Argo CD and CasaOS using native Kubernetes Server-Side Apply with zero custom CRDs.2 min
  8. J.4.8Trawl specificationDesignFirst deterministic worker in cs-workers that discovers public candidates, normalizes URLs, deduplicates via SHA-256, and assigns persistent PA-XXXX IDs with zero runtime AI.3 min
  9. J.4.9Sextant specificationDesignTechnical specification for the deterministic Sextant worker that inspects public pages, spawns on-demand browser Jobs, and seals raw captures behind the clean-room wall.4 min
  10. J.4.10Assay specificationDesignTechnical specification for the deterministic Assay worker that executes five binary knockout gates, the 100-point rubric, and five tie-breakers using YAML/Go rules.3 min
  11. J.4.11Countersign specificationDesignTechnical specification for Countersign, the human-accountability queue worker powering tool determinations and anonymous edit approvals on /guides/#decide.3 min
  12. J.4.12Waybill specificationDesignTechnical specification for the deterministic Waybill worker that stamps Go-template provenance notes, enforces 48h/5d SLAs, and compiles sanitized JSON build specs.3 min
  13. J.4.13Moldloft specificationDesignTechnical specification for the deterministic Moldloft worker that generates isolated MIT static tool repositories from clean-room JSON specs and stack templates.3 min
  14. J.4.14Shakedown specificationDesignAutomated 5-condition verification worker that tests built static tools for offline execution, strict CSP, zero tracking, worked examples, and public citations before catalog publication.3 min
  15. J.4.15Chartroom specificationDesignCatalog publication worker that publishes verified, linked, merged, and retired entries with provenance links to the clearedstack.com catalog.2 min
  16. J.4.16Tidegauge specificationDesignScheduled monitoring worker that watches FAR/DFARS/NIST feeds, live tools, linked tools, and parked blockers for deterministic drift and reopens affected items.3 min
  17. J.4.17Bellbuoy specificationDesignCross-cutting routing and notification worker that deduplicates errors by fingerprint, commits approved Portal edits and needs_subtool tasks to Plainforge, and drives owner alerts and live SSE updates.3 min

Naming registry

17 components, each with a name of its own.

Every part of the platform has one canonical name, chosen to describe what the part is responsible for and not how it is built, so the name survives a change of implementation. Each name links to that component’s specification, which carries its full entry: boundaries, repository, container image and dependencies. These are the parts of the factory, not tools for contracting work. Those are in the catalog.

The registry is one file, src/data/registry.json, also published as /platform/registry.json for manifests, pipelines and other repositories to read. A name is changed there and nowhere else.

Pipeline workers · in stage order
NameFormerlyResponsible forDepends on
01Trawlcs-01-intakeFinds candidate tools and records each one exactly once.Muster
02Sextantcs-02-observethen SpyglassReads a candidate's public pages and writes down what job it does, copying nothing.Muster
03Assaycs-03-evaluateScreens each candidate against the knockout gates and scores it on the rubric.Muster
04Countersigncs-04-decidethen GavelHolds scored candidates and edit proposals until a person decides.Muster
05Waybillcs-05-provenanceCredits where an idea came from and writes the specification a tool is built from.Muster
06Moldloftcs-06-buildthen JigGenerates a tool's repository from its specification and a fixed template.Muster, Plainforge
07Shakedowncs-07-verifyChecks a built tool against the five listing conditions before it can be listed.Muster
08Chartroomcs-08-catalogthen GazettePublishes, links, merges and retires catalog entries.Muster, Plainforge
09Tidegaugecs-09-monitorthen DogwatchWatches official sources, live tools and linked tools for change, and reopens whatever is affected.Muster
10Bellbuoycs-10-notifythen FoghornTurns failures, paused items and approved edits into one piece of work in the repository that owns the fix.Muster, Plainforge
Control plane
NameFormerlyResponsible forDepends on
Connclearedstack-webShows the catalog, the guides and the state of the factory to anyone, and takes in edit proposals.Logbook, Muster
Musterhub-queue-apiHands out work to the workers, records every result and change of state, and receives edit proposals.Logbook
LogbookpostgresKeeps the record of every item, decision and proposal, and the public views of that record.—
Plainforgecs-gitHolds the primary copy of every repository, announces each change and mirrors code outward.—
Lazarettecs-registrythen StowKeeps built images inside the cluster, with recent versions ready for rollback.—
Keelworkscs-runnerthen SlipwayTests, builds and signs an image for every change.Plainforge, Lazarette
Shipkeepercs-storethen BosunDeploys what was built, keeps it in its intended state and reports its health with cluster details removed.Plainforge, Lazarette, Muster