This project uses Linked Literate Programming (LLP) as defined in LLP 0000. Read that document before making substantial changes.
- LLP documents live flat in
llp/and follow the numbering conventionNNNN-slug.type.md(e.g.0001-foo.guide.md). Sub-LLPs nest by dotted number:0001.000-foo-spec.spec.mdis the first child of LLP 0001, to any depth. Numbers are never reused and a document is never renamed to re-parent it. llp/current/andllp/foundation/hold relative links only (symlinks, or regular files containing the relative path on checkouts without symlink support).current/is the declared working set: link a new or in-progress LLP there and remove the link when the work is done — that is the archive operation.foundation/is the kernel from which the design could be recreated (LLP 0000's admission test); promote into it by folding settled decisions into a livingActivedocument, then linking it. It may be empty early on. Orient by readingfoundation/, thencurrent/, then the@refs in scope.- When creating a new LLP, use the next available number and include the standard metadata header (
Type,Status,Systems,Author,Date; optionalRole,Revised,Related). - Standard types: RFC, Spec, Decision, Plan, Explainer, Principles, Guide, Issue, Research. Define others if none fit.
- Review intensity is stakes-scaled and author-judged (LLP 0005): setting
Status: Reviewis the opt-in to a formal multi-model loop; the honesty rules (never fabricate a review, artifacts underllp/reviews/, the author decides) always apply. - LLP documents are living documents. Update them when the system evolves; mark wrong or replaced ones
Tombstoned/Supersededin the header (files never move). Don't leave stale docs unmarked. - Corpus content is contract or recipe: advisory how-to is marked
> **Recipe (advisory)**and is deletable; normative rules are not (LLP 0004, "Contracts over recipes").
- When writing or modifying code that implements a non-obvious design decision documented in an LLP, add an
@refannotation:// @ref LLP NNNN#section — short gloss - When modifying code that already carries a
@ref, check that the referenced section still applies. Update or remove it if not. - Don't annotate mechanically. A reference should tell you something you wouldn't know from reading only the code and filename.
- Run
./ref-checkto validate references and metadata deterministically (CI runs it on every push). Drift that takes judgment isllp-maintain's job.
This repo ships LLP workflow skills under skills/ (see the README's Skills section). The orient-first rule below is the ambient guidance; the skills are what it routes to.
Before editing a subsystem with documented design, orient first: read its
governing LLP, and for non-trivial work invoke llp-orient to assemble a
context pack of the constraints the change must respect.
Skills: orient = context before coding · create = author one LLP · review = LLP 0005 loop, scaled to stakes · adopt = set up LLP in any repo or package, interview-first retrofit, install/update the skills · maintain = drift / pre-PR / reconcile / retire / curate (promote → archive → realign, LLP 0011.000) · super-refine = dual-model refine-until-ready · ship = tasks done end to end
- Read relevant LLP documents before implementing features or fixing bugs in the areas they cover.
- If you make a design decision worth documenting, write or update an LLP for it.
- Prefer updating an existing LLP over creating a new one when the topic is already covered.
- Land doc updates in the same commit as the code change that motivated them (co-evolution, LLP 0004).