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 |
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 builtLinks
- github.com/cx-home/cx-decisions — the repository
- README — what it is, how to install it, what it pins
- The front door pins nothing of this repository, so no checkout of it is in the tree this page was built from: the two links above are the registry's row, fetched by the site's external-link step and verified against no tree here; its specification and its corpus, where it keeps them, are its own.