CX · Reference guidecx-decisions
PlaygroundDownloadsAboutv0.18.0-pre.1

cx-decisions

the ledger, the process specs, the standing rules, design texts

Why reach for it

A decision is written down once, and a commit that cites it has to find it. cx-decisions is the record: the ledger of every ruling under its id, the process specs that give the work its vocabulary — release, epic, issue, decision; branch, merge; owner, integrator, agent; step, pipeline, run — the standing rules every agent reads before its brief, and the design texts a ruling was argued from.

A RULED: <id> in a commit subject is not decoration: the freeze gate resolves every id against the ledger and refuses a commit that names a decision the ledger does not carry, and the ledger's index maps every id to the file and heading that carries it — so a rule is either recorded or it is not a rule. The ledger records decisions; it does not make them. The spec is the only truth, and a decision that changes it is an edit to the spec inside the decision, never a document beside it.

What is here is what every other repository reads and none of them owns: the delivery grammar, governance, the readiness rubric and the release process; the pin-document format every deps.cxd follows; the standing rules; the working specs and the archived ones; the design texts and each release's own record. The tree this site was built from keeps the tracked copies its gates read, and this repository is the record published for the rest.

What it gives you

No module and no code: the repository is text — the ledger, the process specs, the rules and the designs — so the table below is the generator's note. What it gives you is the reason behind every RULED: on this site.

This repository ships no bundled module of its own; what it gives you is above, and its links are below.

Try it

A decision and its executable end, side by side. This case's own notes name the ledger page that ruled it: a monitor's batch receive answers the channel family's terminal when there will never be anything more — a drained monitor, a closed one — instead of an empty answer that could also mean not yet, and the corpus pins exactly that. The case is the language corpus's; the ruling it cites is a page of this repository's ledger.

prog.cx

        [?let [= $w [?worker name="quick" [+ 1 1]]]
[= $mon [?monitor $w]]
[= $all [?receive from=$mon max=2 deadline=5000]]
[= $drained [?receive from=$mon max=2 deadline=100]]
[= $mon2 [?monitor $w]]
[= $cl [?close $mon2]]
[= $closed [?receive from=$mon2 max=1]]
  ($all, $drained@code, $closed@code)]
      
        $ cx prog.cx
(([spawned name=quick], [done name=quick 2]), 'cx-err:CXER0200', 'cx-err:CXER0200')
      

Fixture program-conc-028b-monitor-batch-terminal-answers in deps/cx-core-code/conformance/code.cxd — replayed against this cx when the page was built.

Status

The front door pins nothing of the record — its gates read their own tracked copies of the ledger and the process specs — so the registry row carries an at= and deps.cxd carries no row, and the figure draws the repository alone. Nothing builds on it in the build's sense; everything is ruled by it.

fact as the registry records it
ships as none
status extracted
pinned at 03c77ec22 — the registry's at=; deps.cxd carries no row for it, so nothing of it is in the build
builds on none recorded — the registry row carries no pins= column yet
built on by nothing pins it yet
bundled modules 0
BUILDS ON THIS REPOSITORY · SHIPS BUILT ON BY none recorded — no pins= on the registry row yet cx-decisions no bundled module — see its row nothing pins it yet DRAWN FROM registry/repos.cxd's pins= COLUMN AND registry/modules.cxd WHEN THIS PAGE WAS BUILT
Fig. — what cx-decisions plugs into: the repositories it builds on (left), the modules it ships (centre), the repositories that build on it (right) · drawn from registry/repos.cxd, deps.cxd and registry/modules.cxd when this page was built