This folder shows how adopters can apply the methodology. The fictional example-project/ is pinned to v1.28.0; the software-squad walkthrough illustrates v1.35.0. Neither is evidence of external adoption.
| Folder | Purpose | Read this when |
|---|---|---|
methodology/ |
The abstract rules (the what and why). | Learning the methodology; deciding whether to adopt it. |
self-development/ |
The methodology applied to its own development (a real, meta, instance). | Seeing the methodology used on a non-trivial project; understanding how the autonomous loop actually runs. |
examples/ (this folder) |
A fully-worked illustrative project (tinker, a fictional developer-notes CLI). |
Seeing how the abstract docs translate to concrete artifacts on a hypothetical adopter project; lifting patterns directly. |
The three are complementary: read methodology/ to understand the rules; read self-development/ to see them on a real project; read examples/ to see them on a synthetic project that strips out the meta-ness.
Software squads — solo and three-person software delivery, assurance, capacity, and blocked acceptance (v1.35.0).
example-project/README.md — the fictional tinker project’s intro.example-project/strategy/00_master_plan.md — strategy doc following the 01_strategy.md skeleton.example-project/pillars/ — two example pillars following the 02_pillars.md skeleton.example-project/backlog/EPICS.md — epic rollup.example-project/backlog/epics/E01-cli-foundations/ — one epic with all 5 standard files (README, BACKLOG, ARCHIVE, FUTURE, TEST) demonstrating the canonical table-form frontmatter from 04_backlog_items.md and the 03_epics.md “Standard epic-folder structure”.example-project/backlog/TEST_BACKLOG.md — cross-epic manual-QA queue (pairs with each epic’s per-epic TEST.md).example-project/backlog/HUMAN_NEEDED.md — the blocked-item protocol in full: BL-0005 is blocked, its lock is released, its body carries a Blocker: line, and the registry entry says what only a human can decide. Read the three together — the protocol only makes sense as a set.example-project/backlog/ACTIVE_CONTEXT.md — volatile session state, caught mid-item, with an explicit note on what deliberately isn’t in it.example-project/memory/ — the two-layer memory with three active entries and one archived. Shows the entry format, a pinned entry (a latency budget whose own success makes it look unused), the admission test applied — nothing derivable from the repo is stored — and an archived entry showing the healthy retirement path: the lesson became a test, so the entry retired.tinker is a deliberately fictional developer-notes CLI. It does not resemble any specific real product — the goal is to be plausible enough that the methodology artifacts look realistic, while generic enough that adopters can map their own project’s shape onto it. The example does not include working source code; it’s docs-only, the same scope this methodology project itself produces.
All content in this folder follows the same abstract-voice constraint as the methodology docs themselves: no real product names, no specific company references, no domain jargon revealing a source project. The original example-project/ was reviewed by a fresh cross-AI session for abstract-voice compliance before ship. That historical review does not cover later examples; the squad walkthrough has author checks only until its release review is recorded.