Kernel
10 files — canonical doctrine — machine-loaded YAML
YAMLkernel/context-thrift.yaml4.1KB · 2026-07-16 · 2:10 PM
This is the machine-readable context-thrift kernel. Its ten rules control how the orchestrator delegates reading, uses monitors instead of polling, filters at the source, chooses cheap surveys versus deep audits, tiers models, stores state on disk, batches human communication, prevents append races, and instruments the physical context meter.
e.g. CT4 sets an approximate steady-state ratio of twenty cheap one-line looks to one deep audit.
YAML — The machine-readable formatCT1-CT10 — The ten context-thrift rule identifiersKB — Knowledge-base pattern identifierRESUME.md — On-disk state/handoff recordRAM — Random-Access MemoryL94 — The lesson requiring action on an instrumented thresholdL100 — The stale detached-watcher lesson
YAMLkernel/delegation.yaml9.0KB · 2026-07-16 · 5:09 PM
Entabeni's DELEGATION doctrine — its equivalent of the god kit's executors routing: how a unit of work is assigned to an executor/model for this engagement. Kept as its own kernel file here (the god kit folds routing into executors.yaml).
e.g. Rules for which tickets a conductor keeps vs hands to a worker seat.
YAMLkernel/executors.yaml9.9KB · 2026-07-16 · 5:01 PM
This is the canonical roster and routing table for worker and side-task seats. It defines headless launch profiles, flags, models, grounding files, caps, authentication, gotchas, the L0–L4 orchestra layers, NotebookLM verification, dispatch preflight, task-shape routing, the escalation ladder, quota/machine fallbacks, and family-parity rules.
e.g. The codex-cli profile uses `codex exec --sandbox workspace-write -o <file> -m <model>`, while the grok profile requires a PTY, JSON output, and `--always-approve` for detached tool use.
YAML — The machine-readable executor formatCLI — Command-Line InterfacePTY — Pseudo-terminalTTY — Terminal device interfaceAPI — Application Programming InterfaceSSH — Secure ShellL0-L4 — Conductor, in-family, external CLI, verification, and local-glue layersL5 — Usage-cap lesson used in dispatch preparationL29 — The pre-launch quota-probe lessonL115 — The weak-before-strong cross-vendor lessonL116 — The turnkey-enforced delegation-ladder lessonKB — Knowledge-base pattern identifierJSON — JavaScript Object NotationHTTP — HyperText Transfer Protocol429 — HTTP rate-limit statusxAI — The vendor family providing GrokNPU — Neural Processing Unit
YAMLkernel/guardrails.yaml14.5KB · 2026-07-17 · 12:27 PM
Entabeni's GUARDRAIL set — the build-failing checks that enforce 'the Entabeni way' (backend treated as sacred, gate fails on red, no unverified ledgers). The god kit splits this into guardrail-admin.yaml plus per-domain candidates; the leaner entabeni kernel keeps one guardrails.yaml.
e.g. A guard that fails the build if a worker mutates the source-of-truth backend contract without authorization.
G- — a build-failing guardrail id
YAMLkernel/intake.yaml8.5KB · 2026-07-04 · 9:20 PM
This is the machine-readable intake schema and conduct guide. It distinguishes spec-stage from idea-stage projects, supports catalog or rolling slicing, declares blocking versus defaulted questions, and emits project.env, pipeline.yaml, guardrails.yaml, and—when needed—a newly transcribed SPEC.md.
e.g. Q-BACKUP is always asked and requires a backup target, cadence, and tested restore rather than a vague claim that data is safe.
YAML — The canonical intake data formatQ- — Intake-question identifierG-ID — Build-failing guardrail identifierAPI — Application Programming InterfaceSSH — Secure ShellL30 — The idea-stage question-by-question intake lessonL31 — The human's slicing choice lessonL44 — The deadline-as-intake-answer lessonL101 — The standing storage-question lessonL102 — The rate-ceiling/concurrency lessonL103 — The goal request is not consent to mutate the host lessonKB — Knowledge-base pattern identifierSPEC.md — A Markdown project specification
YAMLkernel/knowledge-base.yaml20.8KB · 2026-07-04 · 4:43 PM
This is the reusable pattern catalog that lets an agent inherit the kit's playbook without rereading every incident. It groups fable-native and session-adopted patterns for reasoning, orchestration, context management, resources, quality, honesty, routing, instrumentation, and derived kits, cross-linking each pattern to principles, lessons, tools, or examples.
e.g. KB-LEDGER-GROUND-TRUTH-SPLIT says STATUS is a cheap human-readable oversight ledger, while progress and done decisions come from commits, files, or records.
YAML — The canonical pattern-catalog formatKB — Knowledge-base pattern identifierP — Principle identifierL — Lesson/scar identifierCT — Context-thrift rule identifierBC — Behavioral contract identifierAPI — Application Programming InterfaceSSH — Secure ShellMV3 — Manifest Version 3 for browser extensionsTCC — macOS Transparency, Consent, and ControlOOM — Out of memoryACK — Directive acknowledgementPROV — Provisional scar prefixEL — Entabeni-kit scar prefix
YAMLkernel/lessons.yaml31.8KB · 2026-07-17 · 9:58 AM
The CANONICAL scar log for THIS derived instance — the Entabeni engagement's OWN closed id-space, EL-* ("Entabeni Lesson"), carrying 25 EL-scars and ZERO god-kit L-* ids. Append-only; never delete an entry. Lessons live here and evolve independently — a lesson only becomes a god-kit L-scar by deliberate promotion (EL→L), never by automatic sync. This is why the drift page watches Entabeni rather than resyncing it: the god kit's harvester promotes selected EL-lessons up, but the instance is never clobbered by ship-kit.sh.
e.g. e.g. an EL-scar distilled from a real POS-POC or lodging engagement incident on Mac B — grounded in Entabeni's own repos, not the 29-app Holt build the god kit's L-scars came from.
EL — Entabeni Lesson — this instance's own scar-id prefix (25 ids), independent of the god kit's L-* scarsL — the god kit's canonical scar-id prefix (promotion EL→L is deliberate)
YAMLkernel/orchestration.yaml8.4KB · 2026-07-04 · 4:40 PM
This is the canonical machine lifecycle and recovery specification. It defines phases 0–7, pilot validations, fan-out and watch instruments, response classes, done-audit checks, deployment gates, cold_start and worker_stop recovery, structural self-correction, side-task courier rules, and live_testbed feedback for deployed kernel-bearing units.
e.g. On a usage cap it requires notifying the human once, sweeping every other lane backed by that executor, probing before new launches, and using the fallback pool immediately.
YAML — The canonical lifecycle formatP8 — The fix-the-class principleL22 — The corrupt-control-bus lessonL24 — The marker-is-a-claim lessonL28 — The cold-user product-walk lessonL29 — The lane-quota-probe lessonL35 — The apparatus-stays-out-of-artifact lessonL39 — The reviewer-minted-marker lessonL94 — The actionable-threshold lessonL115 — The weak-before-strong routing lessonL116 — The turnkey delegation lessonKB — Knowledge-base pattern identifierBC — Behavioral contract identifierSSH — Secure ShellAPI — Application Programming InterfaceACK — Directive acknowledgementPROV — Provisional scar prefix
YAMLkernel/principles.yaml5.9KB · 2026-07-04 · 9:20 PM
This is the ordered machine canon of the kit's twelve principles. Each principle has an identifier, rule, application or scar link, and lower IDs take precedence when principles conflict.
e.g. P4-PILOT-FIRST requires one unit end to end before fan-out and widens concurrency from 1 to 3–4 only after the pilot works.
YAML — The canonical principles formatP1-P12 — The twelve ordered principle identifiersL1 — The fabricated-ledger scar linked to empirical verificationL4 — The pause/resume scarL6 — The prior-art/fix-the-class scarL9 — The spec-change propagation scarL30 — The intake conduct scar
YAMLkernel/small-window.yaml4.2KB · 2026-07-16 · 5:09 PM
This is the command-activated tight-context operating mode. It defines SW1–SW7: work from a short activation card, act at roughly 50% context and add no new multi-step scope past 60%, keep the handoff current, delegate reading, size atoms to a session, know reset ceilings, and revalidate detached state on re-entry.
e.g. SW5 says an atom larger than one worker lifetime should be split because it will otherwise restart-loop and never land.
YAML — The machine-readable mode configurationSW1-SW7 — The seven small-window operating rulesL94 — The lesson requiring action on context thresholdsL99 — The atom-must-fit-a-worker-lifetime lessonL100 — The detached-watcher/session-id lessonCT — Context-thrift rule familyRESUME — On-disk handoff/state record
Skills
4 files — the entry commands a session invokes
MDskills/begin/SKILL.md4.8KB · 2026-07-16 · 4:52 PM
This is the /begin skill for booting a new project into the think-like-fable method. It locates and freshness-checks the kit, activates domain and lesson guards, runs intake, prepares executor pools and OS posture, proves a representative pilot, fans out in waves, watches exceptions, and finishes with audited completion and provisional scar harvesting.
e.g. Before fan-out it requires a routing table mapping every unit to its weakest-capable escalation rung and a probe dispatch for every named vendor pool.
SKILL — An invocable agent workflow documentL30 — The lookup/intake lesson referenced by beginL34 — The single-writer canonical-numbering lessonL94 — The context-threshold lessonL97 — The activate-the-kit lessonL113 — The do-not-boot-deep-context lessonL115 — The weak-before-strong routing lessonL116 — The turnkey delegation lessonPROV — Provisional local scar prefixSSH — Secure ShellYAML — The agent-facing configuration formatACK — Directive acknowledgement
MDskills/continue/SKILL.md5.0KB · 2026-07-16 · 4:52 PM
This is the /continue skill for re-entering either a kit-managed fleet or an ordinary project already in progress. It supports a one-word scoped handoff token, reconstructs state from disk and ground truth, classifies units, asks only questions disk cannot answer, and proposes concrete relaunch, audit, or adoption steps.
e.g. For a fleet it distinguishes DONE+DIRECTIVES from DONE-MARKED and requires draining open bus directives before auditing a marker.
SKILL — An invocable agent workflow documentL1 — The empirical verification/fabrication lessonL97 — The activate-the-kit lessonL100 — The detached watcher re-entry lessonL110 — The shared-workspace bare-continue pollution lessonCT1 — The delegate-reading context ruleYAML — The machine-readable configuration formatDONE — A completion claim or markerPROV — Provisional scar prefix
MDskills/dogfood-it/SKILL.md2.0KB · 2026-07-16 · 5:09 PM
This is the /dogfood-it skill for executing a previously written DOGFOOD.md plan autonomously against the real product. It uses the live browser, API, CLI, or device path, records evidence and verdicts per step, and explicitly treats green tests as insufficient; it fronts human review but never replaces it.
e.g. A CLI product is driven through its actual command path and the response bodies or log lines are recorded for each planned step.
SKILL — An invocable agent workflow documentAPI — Application Programming InterfaceCLI — Command-Line InterfaceL92 — The lesson that liveness or green tests are not qualityEL16 — An Entabeni lesson cited for verify-don't-trustDOGFOOD.md — The human-rerunnable manual product-walk plan
MDskills/dogfood/SKILL.md2.0KB · 2026-07-16 · 5:09 PM
This is the /dogfood skill for producing a concrete human-review plan after a unit, feature, or phase completes. It grounds the plan in the actual diff and surface, gives exact entry steps and expected results for every touched flow, adds edge probes, defines a pass bar, and specifies where breakage is reported.
e.g. A step must say things like open an exact URL, click an exact label, or type exact data; `navigate to the relevant page` is explicitly not enough.
SKILL — An invocable agent workflow documentL12 — The use-before-done lessonL62 — The exact-courier-detail lessonDOGFOOD.md — The self-contained human product-walk documentURL — Uniform Resource LocatorAPI — Application Programming InterfaceCLI — Command-Line Interface
Tools
12 files — fleet apparatus copied into _build/
SHtools/assess.sh3.5KB · 2026-07-14 · 3:16 PM
This is the read-only fleet state classifier used by /continue. It combines progress, done markers, process liveness, unit ledgers, open CONTROL directives, ground-truth atom totals, and blockers to classify each unit as RUNNING, DEAD, PAUSED, STOPPED, BLOCKED, DONE-CLAIMED, DONE-MARKED, or a directive-conflicted state with a suggested action.
e.g. It checks liveness before pending directives so an alive worker is reported RUNNING rather than incorrectly suggested for relaunch.
sh — Shell script file suffixCONTROL — Per-unit command busSTATUS — Per-unit ledgerDONE — Completion claim or markerL18 — The lesson fixing classifier ordering and scope measurementF8 — Ground-truth substitution/configuration fixF13 — Single-worker lease guard identifierGit — Distributed version-control systemPID — Process identifier
SHtools/audit-done.sh4.5KB · 2026-07-14 · 3:15 PM
This is the integrity gate for a unit's DONE claim. It compares ledger atom claims with ground-truth counts and spec totals, checks substantive completion files, requires a structural PRODUCT WALK section with per-flow PASS/FAIL evidence, and exits nonzero when the claim is incomplete, fabricated, or un-auditable.
e.g. A line such as `F1 — PASS (evidence: screenshot.png)` satisfies the product-walk shape, while a bare word like `dogfood` does not.
sh — Shell script file suffixDONE — Completion claim or markerSTATUS — Per-unit ledgerDOGFOOD — Using the product as a real userPRODUCT WALK — Cold-user flow verificationPASS/FAIL — The required per-flow verdict formATOM-ID — Countable work-item identifierF7 — The product-walk format synchronization fixF8 — The unit/slug ground-truth substitution fixL28 — The product-walk integrity lessonYAML — The control-bus/config format
SHtools/bus-sweep.sh905B · 2026-07-14 · 3:17 PM
This is the fleet-wide control-bus parser check used after unattended windows or injector repairs. It requires Python and PyYAML before judging parse state, loads every unit CONTROL.yaml, prints corrupt paths, and exits nonzero if any bus fails to parse.
e.g. Its clean result is `bus sweep clean (N buses parse)`; a malformed unit bus prints `CORRUPT: <path>`.
sh — Shell script file suffixYAML — The control-bus data formatPyYAML — Python's YAML parser libraryCONTROL — Per-unit directive busL22 — The bus-can-be-the-fault lessonL7 — The prove-the-bus lessonL — Lesson/scar identifier
SHtools/dashboard.sh1.4KB · 2026-07-04 · 9:17 PM
This is the human-facing one-shot live dashboard for workers. It prints one block per queued unit with an alive marker, current atom, last gate, blockers, and the last meaningful narration line after stripping diffs and execution noise; it is meant for repeated `watch` display, not raw log tailing.
e.g. A row looks like `● unit | current-atom | last-gate | blockers`, followed by a single concise narration line.
sh — Shell script file suffixSTATUS — Per-unit ledgerCT1 — The delegate-reading context ruleGit — Distributed version-control systemPID — Process identifier
SHtools/dogfood-verify.sh3.4KB · 2026-07-14 · 3:16 PM
This is the machine-runnable half of a unit dogfood check. It runs the unit's own tests, seed twice for idempotency, the same gate reviewers use, service boot and health probes when configured, and a comparison of spec flow IDs with DOGFOOD.md coverage; human walkthroughs remain separate.
e.g. If a package declares a `seed` script, it runs it twice and reports `seed x2 (idempotent) PASS` only when the second run also succeeds.
sh — Shell script file suffixDOGFOOD — Real use of the built artifactAPI — Application Programming InterfaceHTTP — HyperText Transfer ProtocolL15 — Verify through the unit's own command lessonL16 — Dogfood is run, not merely documentedF — User-flow identifierJSON — JavaScript Object NotationPID — Process identifier
SHtools/gate.sh2.2KB · 2026-07-14 · 3:14 PM
This is the per-unit merge gate and the single definition of green. It loads project.env, runs the configured project gate or package gate, refuses an empty gate as a lie, prints each check, and exits nonzero with GATE FAIL when any check fails.
e.g. With no GATE_CMD, no package `gate` script, and no uncommented checks, it emits `GATE FAIL: no checks defined` instead of passing vacuously.
sh — Shell script file suffixGATE_CMD — Configured command used as the unit gatePASS/FAIL — Gate result statesCI — Continuous IntegrationL15 — The verify-via-own-command lessonWF-4 — The empty-gate failure classGit — Distributed version-control system
SHtools/inject.sh3.0KB · 2026-07-14 · 3:17 PM
This is the append-only control-bus writer. It validates directive type and argument shape, requires a YAML parser, normalizes inline directives, guarantees a trailing newline, emits multiline instructions as a block scalar, parse-checks the whole file, and rolls back a poisoning append.
e.g. `inject.sh <unit> pause general "stop after checkpoint"` appends a numbered OPEN directive and reports `parse-verified`.
sh — Shell script file suffixYAML — The control-bus data formatPyYAML — Python's YAML parser libraryOPEN — Directive status awaiting execution and acknowledgementACK — Worker acknowledgementL7 — The bus liveness lessonL22 — The corrupt-bus lessonKB — Knowledge-base pattern identifierISO8601 — International date/time format
SHtools/keep-fed.sh3.0KB · 2026-07-04 · 9:17 PM
This is the supervisor loop that repeatedly relaunches one-shot workers until audited done markers cover all requested slugs or a safe stop condition occurs. It audits fresh markers, compares Git HEAD fingerprints for progress, stops on pool failure, no-progress rounds, maximum rounds, or a competing supervisor lock.
e.g. After three rounds with no Git HEAD movement it exits 4 as a silent-dead pool instead of churning fifteen retries.
sh — Shell script file suffixGit — Distributed version-control systemHEAD — The current Git commit referenceDONE — Completion marker/claimMAX_ROUNDS — Maximum relaunch-round settingNO_PROGRESS_MAX — Allowed consecutive no-progress roundsAUDIT_MARKERS — Setting that gates markers through audit-done.shL4 — Resume-by-ledger lessonL24 — Marker-is-a-claim lessonL98 — Single supervisor lessonPID — Process identifier
SHtools/lib.sh2.2KB · 2026-07-14 · 3:17 PM
This is the shared shell helper library for recurring structural fixes. It provides safe numeric grep counts, trailing-newline repair, and a distinct PyYAML/python3 dependency preflight so injectors and bus sweeps do not confuse a missing parser with a corrupt bus.
e.g. `require_yaml_parser` exits with `MISSING DEPENDENCY: PyYAML` before any parse verdict when the yaml module is absent.
sh — Shell script file suffixPyYAML — Python's YAML parser libraryYAML — The control-bus/config data formatL7 — The prove-the-bus lessonL18 — The prose-lesson-is-not-a-fix lessonpython3 — Python 3 interpreter
SHtools/pool.sh5.1KB · 2026-07-14 · 3:19 PM
This is the concurrent one-shot worker launcher. It reads project.env, probes the actual executor pool, resolves per-slug executors and models, renders worker-prompt.md, refuses unresolved placeholders or missing workspaces, enforces a per-unit lease, detaches the worker from the caller's process group, logs the real exit code, and waits for up to K workers.
e.g. Before launching it checks that `worker-prompt.md` is beside pool.sh and rejects a residual `{UNIT_VAR}` placeholder rather than spending a worker turn guessing.
sh — Shell script file suffixK — Maximum number of concurrent workersCLI — Command-Line InterfaceGit — Distributed version-control systemPID — Process identifierL29 — Pre-launch quota-probe lessonL45 — Worker cwd/grounding lessonL63 — One-shot worker lessonL66 — Detached-session/process-group lessonF6 — Worker prompt placeholder substitution fixF13 — Per-unit lease fixEXIT_CODE — Recorded process exit status
SHtools/progress.sh1.4KB · 2026-07-04 · 9:17 PM
This is the fleet progress calculator. For each queued slug it substitutes unit and slug paths into configured total/done commands, counts ground-truth atoms rather than ledgers, loudly excludes a misconfigured zero total, floors the denominator when scope grows, and prints one percentage line suitable for change-triggered monitoring.
e.g. If a unit grows from 10 planned atoms to 12 completed atoms, it reports `12/12+` rather than a misleading percentage above 100.
sh — Shell script file suffixATOM_NAME — Configured name for a progress atomATOMS_TOTAL_CMD — Command returning a unit's spec totalATOMS_DONE_CMD — Command returning ground-truth completed atomsF8b — The loud zero-total configuration guardL18 — The scope-measurement lessonGit — Distributed version-control system
SHtools/watch.sh763B · 2026-07-04 · 9:17 PM
This is the cheapest cross-unit survey tool. It prints one block per unit with the count of open control directives and the compact STATUS fields for milestone, current atom/ticket, last gate, and blockers, making it suitable for a heartbeat instead of raw log reading.
e.g. A unit block begins `=== <unit> OPEN-directives:<n>` and then shows its current ledger header.
sh — Shell script file suffixSTATUS — Per-unit ledgerCONTROL — Per-unit directive busCT1 — The delegate-reading context ruleGit — Distributed version-control system
Templates
6 files — skeletons instantiated per project
YAMLtemplates/CONTROL.yaml1.4KB · 2026-07-04 · 9:18 PM
This is the per-unit YAML seed for the append-only reviewer command bus. It defines directive fields, the seven allowed types, worker acknowledgement expectations, and the open directive shape that inject.sh appends and workers consume at checkpoints.
e.g. A `correct` directive targets an ATOM-ID, names an optional guardrail, carries an instruction, and stays `status: OPEN` until the worker ACKs it.
YAML — The control-bus data formatACK — Acknowledgement that a worker executed a directiveATOM-ID — Identifier for a countable work atomG-ID — Build-failing guardrail identifierISO8601 — International date/time representationL7 — The control-bus proof lesson
MDtemplates/STATUS.md1.2KB · 2026-07-04 · 9:19 PM
This is the per-unit Markdown ledger template. Workers overwrite its small header with the current unit, milestone, atom, gate, landed evidence, promotions, and blocker state, then append notes about assumptions, directives, self-dogfood, and anything a reviewer needs to trust.
e.g. The header includes `last-gate: PASS|FAIL @ <ISO8601>` and `blockers: none|PAUSED|STOPPED|DONE`.
MD — Markdown document formatISO8601 — International date/time representationG-STATUS-CURRENT — Guardrail requiring the ledger header to reflect realityDONE — Completion claim/markerPAUSED — Worker parked for later resumeSTOPPED — Worker stopped by directive
YAMLtemplates/guardrails.yaml2.5KB · 2026-07-04 · 9:18 PM
This is the project guardrail skeleton filled from intake. It names invariants such as no-touch-existing, standalone units, a nonempty gate, control-bus ordering, current status, and use-before-done, and pairs each with an enforcement mechanism or a placeholder for a project-specific failing check.
e.g. G-USE-BEFORE-DONE requires realistic self-use and a cold user completing every core flow, and points the reviewer to done-audit evidence.
YAML — The guardrail configuration formatG- — Build-failing guardrail identifierG-NO-TOUCH-EXISTING — Guardrail limiting a worker to its own workspaceG-GATE — Guardrail making gate.sh the definition of greenG-STATUS-CURRENT — Guardrail requiring evidence-backed ledger stateG-USE-BEFORE-DONE — Guardrail requiring self-use and cold-user completion
YAMLtemplates/pipeline.yaml4.9KB · 2026-07-04 · 9:22 PM
This is the canonical per-project pipeline template. It defines paths, atoms and evidence, the worker loop, milestones, gate command, control-bus obligations, completion requirements including seed/self-use/product walk/runbook, and the integrity rule that an evidence-less ledger claim voids the build.
e.g. Its work loop says a worker must re-read CONTROL.yaml, execute and ACK open directives, implement one atom, re-read before a checkpoint, run the gate, and land evidence only after PASS.
YAML — The machine-readable pipeline formatGit — Distributed version-control systemATOM-ID — Countable work-item identifierACK — Directive acknowledgementDOGFOOD — Using the built artifact as a real userPRODUCT WALK — Cold-user completion of every core flowG-ID — Guardrail identifierSTATUS — Per-unit ledger fileCONTROL — Per-unit directive-bus file
ENVtemplates/project.env4.2KB · 2026-07-16 · 5:01 PM
This is the environment template that parameterizes every fleet tool. It holds project paths, executor and model settings, quota probes, atom ground-truth commands, per-unit ledger names, vendor side-task options, SSH offload settings, and the done-audit contract.
e.g. It defines `ATOMS_DONE_CMD` as a command that must count real commits/files rather than ledger claims and warns that `{unit}` and `{slug}` are literal substitution tokens.
ENV — Environment-variable configurationYAML — The format used by pipeline and control filesSSH — Secure ShellCLI — Command-Line InterfaceAPI — Application Programming InterfaceJSON — JavaScript Object NotationG-ID — Guardrail identifierATOM — Countable work itemOS — Operating SystemL5 — Usage-cap lessonL29 — Pre-launch quota-probe lessonF12 — Worker OS-sandbox guard identifierKB — Knowledge-base pattern identifier
MDtemplates/worker-prompt.md5.1KB · 2026-07-14 · 3:20 PM
This is the agent-facing worker contract rendered by pool.sh for each unit. It binds the worker to the canonical spec, human register, one workspace and branch, one-shot foreground verification, control-bus checkpoints, evidence-backed atoms and milestones, cold-start product walks, shared-machine limits, and a parseable-bus stop rule.
e.g. It explicitly says the worker must not write DONE_FILE; the orchestrator mints the shared marker only after done-audit passes.
MD — Markdown document formatYAML — The structured prompt format after its title line is strippedACK — Directive acknowledgementVCS — Version Control SystemGit — Distributed version-control systemBC — Behavioral contractKB — Knowledge-base patternG-NO-TOUCH-EXISTING — Own-workspace boundary guardrailL39 — Reviewer-minted markers lessonL53 — One-shot worker cannot wait lessonL63 — No blind windows lessonG- — Guardrail identifier
Root docs
4 files — narrative canon + NotebookLM sources
MDLESSONS.md27.7KB · 2026-07-17 · 9:58 AM
This is the human narrative companion to the append-only scar log in kernel/lessons.yaml. It records real incidents, the rule learned from each incident, and the structural fix or related practice, so later projects inherit hard-won safeguards instead of repeating fleet-scale mistakes.
e.g. The scar named L29 records a priority unit receiving zero work because its executor lane was already capped, and turns that incident into the rule to probe each lane before launching it.
L — Lesson/scar identifierPROV — Provisional local lesson identifier before canonical numberingEL — Entabeni-kit lesson identifierKB — Knowledge-base pattern identifierYAML — The data format used by the canonical scar fileL34 — The canonical-owns-the-numbers scar about single-writer lesson allocationL96 — The one-standing-harvester scar about preventing concurrent canonical writes
MDPRINCIPLES.md8.2KB · 2026-07-04 · 4:42 PM
This is the human-readable statement of the kit's twelve ordered principles. It explains why ground truth beats claims, why judgment belongs to the orchestrator, why gates and pilots matter, how to fix systemic classes, how to keep honest ledgers, how to recover from death, and when to ask the human.
e.g. Principle 1 says a DONE claim must be checked against commits, files, records, or a running process before it is accepted.
P1-P12 — The twelve ordered principle identifiersDONE — A completion claim or marker, not proof of completion⚠ — The marker for assumed, deferred, or blocked work
MDREADME.md7.1KB · 2026-07-16 · 8:01 PM
This is the kit's orientation document for a newcomer. It explains that kernel/*.yaml is canonical, the Markdown files are human companions, the fleet method came from a live 29-app build, and the repository contains intake, lifecycle, skills, templates, tools, a terminal blueprint, and a Pi deployment profile.
e.g. Its boot sequence starts by loading `kernel/principles.yaml` and `kernel/lessons.yaml`, then walking intake before instantiating project.env and the pipeline templates.
YAML — A human-readable data-serialization formatMD — Markdown document formatCLI — Command-Line InterfaceLLM — Large Language ModelPyYAML — Python's YAML parsing libraryAPI — Application Programming InterfaceSSH — Secure ShellP — Principle identifierL — Lesson/scar identifierKB — Knowledge-base pattern identifier⚠ — The uncertainty marker
MDUSAGE.md11.2KB · 2026-07-16 · 5:01 PM
This is the longer reference manual for operating a fleet from a populated build directory. It gives quick starts, environment variables, command examples, control-bus procedures, cap and machine fallbacks, terminal/Pi workflows, dogfood expectations, and the full multi-vendor side-task courier protocol.
e.g. For a side-task it writes `.packet.md`, runs `./dispatch.sh start grok AUD-003 /path/to/workdir`, polls bounded `wait` calls, then normalizes the report and re-runs one cited command.
YAML — The machine-readable format parsed for the control busJSON — JavaScript Object NotationSSH — Secure ShellCLI — Command-Line InterfaceAPI — Application Programming InterfacePTY — Pseudo-terminalTUI — Terminal User InterfaceL — Lesson/scar identifierKB — Knowledge-base pattern identifierP12 — The ask-once intake principle⚠ — The uncertainty/deferred marker
Examples
6 files — worked instances from live runs
ENVexamples/cst-slice/project.env3.6KB · 2026-07-16 · 5:01 PM
A WORKED EXAMPLE project.env — the real per-project fleet config for a Customer Success Tool (CST) feature slice — the exemplar of discipline. Shows exactly how the apparatus is filled for an Entabeni unit.
e.g. Sets slug ids, gate command, executor, paths the tools consume.
CST — Customer Success Tool
MDexamples/cst-slice/worker-prompt.md5.9KB · 2026-07-04 · 4:38 PM
A WORKED EXAMPLE instantiated worker prompt for a Customer Success Tool (CST) feature slice — the exemplar of discipline — the actual brief a worker seat receives, with the INTEGRITY clause. pool.sh strips its title line on launch.
e.g. Carries the {slug} substitution (e.g. LODGE-012) and the ticket's acceptance gate.
ENVexamples/lodging-ticket/project.env3.6KB · 2026-07-16 · 5:01 PM
A WORKED EXAMPLE project.env — the real per-project fleet config for a lodging POC ticket (LODGE-NNN) across the lodging system. Shows exactly how the apparatus is filled for an Entabeni unit.
e.g. Sets slug ids, gate command, executor, paths the tools consume.
CST — Customer Success Tool
MDexamples/lodging-ticket/worker-prompt.md5.1KB · 2026-07-04 · 4:39 PM
A WORKED EXAMPLE instantiated worker prompt for a lodging POC ticket (LODGE-NNN) across the lodging system — the actual brief a worker seat receives, with the INTEGRITY clause. pool.sh strips its title line on launch.
e.g. Carries the {slug} substitution (e.g. LODGE-012) and the ticket's acceptance gate.
ENVexamples/scanner-hardware-bug/project.env4.5KB · 2026-07-16 · 5:01 PM
A WORKED EXAMPLE project.env — the real per-project fleet config for a React Native scanner/hardware bug in the hardware family. Shows exactly how the apparatus is filled for an Entabeni unit.
e.g. Sets slug ids, gate command, executor, paths the tools consume.
CST — Customer Success Tool
MDexamples/scanner-hardware-bug/worker-prompt.md6.1KB · 2026-07-04 · 4:40 PM
A WORKED EXAMPLE instantiated worker prompt for a React Native scanner/hardware bug in the hardware family — the actual brief a worker seat receives, with the INTEGRITY clause. pool.sh strips its title line on launch.
e.g. Carries the {slug} substitution (e.g. LODGE-012) and the ticket's acceptance gate.
Profiles
15 files — per-repo engagement maps read before a worker acts
MDprofiles/CNS-PWA.md12.1KB · 2026-07-04 · 9:17 PM
A per-repo CODEBASE PROFILE for the CNS Progressive Web App (PWA = a web app installable like native). It maps the repo before a worker touches it — architecture, conventions, entry points, test/gate commands, and known gotchas — so any model can plan and execute against it 'the Entabeni way'. This is the entabeni kit's signature move: the god kit carries doctrine; a derived engagement kit ALSO carries a map of every repo it builds.
e.g. Header: '# CNS-PWA — Codebase Profile · Generated 2026-07-04 · Repo path: .../CNS-PWA'. A worker reads this first, not the raw repo.
POC — Proof Of ConceptPOS — Point Of SaleBFF — Backend-For-FrontendPWA — Progressive Web AppCST — Customer Success ToolRN — React Native
MDprofiles/Entabeni-POS.md15.4KB · 2026-07-04 · 9:17 PM
A per-repo CODEBASE PROFILE for the point-of-sale (POS) app. It maps the repo before a worker touches it — architecture, conventions, entry points, test/gate commands, and known gotchas — so any model can plan and execute against it 'the Entabeni way'. This is the entabeni kit's signature move: the god kit carries doctrine; a derived engagement kit ALSO carries a map of every repo it builds.
e.g. Header: '# Entabeni-POS — Codebase Profile · Generated 2026-07-04 · Repo path: .../Entabeni-POS'. A worker reads this first, not the raw repo.
POC — Proof Of ConceptPOS — Point Of SaleBFF — Backend-For-FrontendPWA — Progressive Web AppCST — Customer Success ToolRN — React Native
MDprofiles/New-Access-Scanner.md12.9KB · 2026-07-04 · 9:17 PM
A per-repo CODEBASE PROFILE for a React Native access-control hardware scanner. It maps the repo before a worker touches it — architecture, conventions, entry points, test/gate commands, and known gotchas — so any model can plan and execute against it 'the Entabeni way'. This is the entabeni kit's signature move: the god kit carries doctrine; a derived engagement kit ALSO carries a map of every repo it builds.
e.g. Header: '# New-Access-Scanner — Codebase Profile · Generated 2026-07-04 · Repo path: .../New-Access-Scanner'. A worker reads this first, not the raw repo.
POC — Proof Of ConceptPOS — Point Of SaleBFF — Backend-For-FrontendPWA — Progressive Web AppCST — Customer Success ToolRN — React Native
MDprofiles/Rental-Scanner-v2.md15.3KB · 2026-07-04 · 9:17 PM
A per-repo CODEBASE PROFILE for a React Native rental hardware scanner (v2). It maps the repo before a worker touches it — architecture, conventions, entry points, test/gate commands, and known gotchas — so any model can plan and execute against it 'the Entabeni way'. This is the entabeni kit's signature move: the god kit carries doctrine; a derived engagement kit ALSO carries a map of every repo it builds.
e.g. Header: '# Rental-Scanner-v2 — Codebase Profile · Generated 2026-07-04 · Repo path: .../Rental-Scanner-v2'. A worker reads this first, not the raw repo.
POC — Proof Of ConceptPOS — Point Of SaleBFF — Backend-For-FrontendPWA — Progressive Web AppCST — Customer Success ToolRN — React Native
MDprofiles/TicketWindowMobile.md10.2KB · 2026-07-04 · 9:17 PM
A per-repo CODEBASE PROFILE for the ticket-window React Native mobile client. It maps the repo before a worker touches it — architecture, conventions, entry points, test/gate commands, and known gotchas — so any model can plan and execute against it 'the Entabeni way'. This is the entabeni kit's signature move: the god kit carries doctrine; a derived engagement kit ALSO carries a map of every repo it builds.
e.g. Header: '# TicketWindowMobile — Codebase Profile · Generated 2026-07-04 · Repo path: .../TicketWindowMobile'. A worker reads this first, not the raw repo.
POC — Proof Of ConceptPOS — Point Of SaleBFF — Backend-For-FrontendPWA — Progressive Web AppCST — Customer Success ToolRN — React Native
MDprofiles/customer-success-tool.md18.6KB · 2026-07-04 · 9:17 PM
A per-repo CODEBASE PROFILE for the Customer Success Tool (CST) — the kit's exemplar-of-discipline repo. It maps the repo before a worker touches it — architecture, conventions, entry points, test/gate commands, and known gotchas — so any model can plan and execute against it 'the Entabeni way'. This is the entabeni kit's signature move: the god kit carries doctrine; a derived engagement kit ALSO carries a map of every repo it builds.
e.g. Header: '# customer-success-tool — Codebase Profile · Generated 2026-07-04 · Repo path: .../customer-success-tool'. A worker reads this first, not the raw repo.
POC — Proof Of ConceptPOS — Point Of SaleBFF — Backend-For-FrontendPWA — Progressive Web AppCST — Customer Success ToolRN — React Native
MDprofiles/ecommerce-LODGE-POC.md1.5KB · 2026-07-04 · 9:21 PM
A per-repo CODEBASE PROFILE for the lodging ecommerce proof-of-concept (POC = Proof Of Concept). It maps the repo before a worker touches it — architecture, conventions, entry points, test/gate commands, and known gotchas — so any model can plan and execute against it 'the Entabeni way'. This is the entabeni kit's signature move: the god kit carries doctrine; a derived engagement kit ALSO carries a map of every repo it builds.
e.g. Header: '# ecommerce-LODGE-POC — Codebase Profile · Generated 2026-07-04 · Repo path: .../ecommerce-LODGE-POC'. A worker reads this first, not the raw repo.
POC — Proof Of ConceptPOS — Point Of SaleBFF — Backend-For-FrontendPWA — Progressive Web AppCST — Customer Success ToolRN — React Native
MDprofiles/ecommerce.md14.5KB · 2026-07-04 · 9:17 PM
A per-repo CODEBASE PROFILE for the Entabeni ecommerce storefront. It maps the repo before a worker touches it — architecture, conventions, entry points, test/gate commands, and known gotchas — so any model can plan and execute against it 'the Entabeni way'. This is the entabeni kit's signature move: the god kit carries doctrine; a derived engagement kit ALSO carries a map of every repo it builds.
e.g. Header: '# ecommerce — Codebase Profile · Generated 2026-07-04 · Repo path: .../ecommerce'. A worker reads this first, not the raw repo.
POC — Proof Of ConceptPOS — Point Of SaleBFF — Backend-For-FrontendPWA — Progressive Web AppCST — Customer Success ToolRN — React Native
MDprofiles/entabeni-api.md13.1KB · 2026-07-04 · 9:17 PM
A per-repo CODEBASE PROFILE for the core Entabeni backend API (the source-of-truth server). It maps the repo before a worker touches it — architecture, conventions, entry points, test/gate commands, and known gotchas — so any model can plan and execute against it 'the Entabeni way'. This is the entabeni kit's signature move: the god kit carries doctrine; a derived engagement kit ALSO carries a map of every repo it builds.
e.g. Header: '# entabeni-api — Codebase Profile · Generated 2026-07-04 · Repo path: .../entabeni-api'. A worker reads this first, not the raw repo.
POC — Proof Of ConceptPOS — Point Of SaleBFF — Backend-For-FrontendPWA — Progressive Web AppCST — Customer Success ToolRN — React Native
MDprofiles/entabeni-apps.md7.4KB · 2026-07-17 · 12:27 PM
A per-repo CODEBASE PROFILE for the Entabeni apps monorepo (shared front-end apps). It maps the repo before a worker touches it — architecture, conventions, entry points, test/gate commands, and known gotchas — so any model can plan and execute against it 'the Entabeni way'. This is the entabeni kit's signature move: the god kit carries doctrine; a derived engagement kit ALSO carries a map of every repo it builds.
e.g. Header: '# entabeni-apps — Codebase Profile · Generated 2026-07-04 · Repo path: .../entabeni-apps'. A worker reads this first, not the raw repo.
POC — Proof Of ConceptPOS — Point Of SaleBFF — Backend-For-FrontendPWA — Progressive Web AppCST — Customer Success ToolRN — React Native
MDprofiles/jira-support-bff.md10.4KB · 2026-07-16 · 3:07 PM
A per-repo CODEBASE PROFILE for the Jira support Backend-For-Frontend (BFF = a server tailored to one client). It maps the repo before a worker touches it — architecture, conventions, entry points, test/gate commands, and known gotchas — so any model can plan and execute against it 'the Entabeni way'. This is the entabeni kit's signature move: the god kit carries doctrine; a derived engagement kit ALSO carries a map of every repo it builds.
e.g. Header: '# jira-support-bff — Codebase Profile · Generated 2026-07-04 · Repo path: .../jira-support-bff'. A worker reads this first, not the raw repo.
POC — Proof Of ConceptPOS — Point Of SaleBFF — Backend-For-FrontendPWA — Progressive Web AppCST — Customer Success ToolRN — React Native
MDprofiles/lodging-api.md10.4KB · 2026-07-04 · 9:17 PM
A per-repo CODEBASE PROFILE for the lodging system's backend API. It maps the repo before a worker touches it — architecture, conventions, entry points, test/gate commands, and known gotchas — so any model can plan and execute against it 'the Entabeni way'. This is the entabeni kit's signature move: the god kit carries doctrine; a derived engagement kit ALSO carries a map of every repo it builds.
e.g. Header: '# lodging-api — Codebase Profile · Generated 2026-07-04 · Repo path: .../lodging-api'. A worker reads this first, not the raw repo.
POC — Proof Of ConceptPOS — Point Of SaleBFF — Backend-For-FrontendPWA — Progressive Web AppCST — Customer Success ToolRN — React Native
MDprofiles/lodging-front-desk.md13.7KB · 2026-07-04 · 9:17 PM
A per-repo CODEBASE PROFILE for the lodging front-desk operator app. It maps the repo before a worker touches it — architecture, conventions, entry points, test/gate commands, and known gotchas — so any model can plan and execute against it 'the Entabeni way'. This is the entabeni kit's signature move: the god kit carries doctrine; a derived engagement kit ALSO carries a map of every repo it builds.
e.g. Header: '# lodging-front-desk — Codebase Profile · Generated 2026-07-04 · Repo path: .../lodging-front-desk'. A worker reads this first, not the raw repo.
POC — Proof Of ConceptPOS — Point Of SaleBFF — Backend-For-FrontendPWA — Progressive Web AppCST — Customer Success ToolRN — React Native
MDprofiles/lodging-web.md11.9KB · 2026-07-04 · 9:17 PM
A per-repo CODEBASE PROFILE for the lodging system's web client. It maps the repo before a worker touches it — architecture, conventions, entry points, test/gate commands, and known gotchas — so any model can plan and execute against it 'the Entabeni way'. This is the entabeni kit's signature move: the god kit carries doctrine; a derived engagement kit ALSO carries a map of every repo it builds.
e.g. Header: '# lodging-web — Codebase Profile · Generated 2026-07-04 · Repo path: .../lodging-web'. A worker reads this first, not the raw repo.
POC — Proof Of ConceptPOS — Point Of SaleBFF — Backend-For-FrontendPWA — Progressive Web AppCST — Customer Success ToolRN — React Native
MDprofiles/ticket-window.md11.6KB · 2026-07-04 · 9:17 PM
A per-repo CODEBASE PROFILE for the ticket-window web client. It maps the repo before a worker touches it — architecture, conventions, entry points, test/gate commands, and known gotchas — so any model can plan and execute against it 'the Entabeni way'. This is the entabeni kit's signature move: the god kit carries doctrine; a derived engagement kit ALSO carries a map of every repo it builds.
e.g. Header: '# ticket-window — Codebase Profile · Generated 2026-07-04 · Repo path: .../ticket-window'. A worker reads this first, not the raw repo.
POC — Proof Of ConceptPOS — Point Of SaleBFF — Backend-For-FrontendPWA — Progressive Web AppCST — Customer Success ToolRN — React Native