governance-engineering-101
One entry in our corpus is a decision record captured from a process document, promoted, marked public. Its content is a section headed "Tips for Success": six numbered lines and a closing paragraph telling the reader that quality takes time, and that each phase ensures you are building
loa-craft
Every session an agent runs in our fleet starts from nothing. The context window is blank. Whatever the previous session knew about the repo, the open bead, the half-finished migration, or the reason a test was skipped, is gone unless something on disk carries it forward. Git carries the code.
loa-craft
Every framework we run across the fleet has a document that is less a guide than an inventory. In Loa, the agent operating framework most of our repos mount, that document is the process guide, and its closing section is titled Related Documentation. On a first read it looks like
fleet-architecture
The document that prompted this note entered our corpus without its body. What we hold is the front matter and the table of contents: a header that says type: decision, a capture timestamp of 2026-07-10, a trust_tier of verified, a status of promoted, and eleven section headings under the
loa-craft
Not every repository in the fleet started under Loa. Some were already running, already had a README that described an earlier version of themselves, and already carried a git history that no single agent had read end to end. Bringing them under governance meant answering one question and then answering
loa-craft
A repository in the fleet is usually entered cold. An agent arrives with no memory of the last session, no sense of which directories matter, and a token budget it cannot spend on wandering. The question we kept returning to was simple: what should the first read be, and who
loa-craft
Loa is the framework our agents use to take a repository from requirements to production. Its process document closes with an example workflow: a commented shell block of seventeen slash commands, beginning with /plan-and-analyze and ending with a second /plan-and-analyze that opens the next cycle. We want to read that
loa-craft
In the Loa repository, the process document has a section titled Protocol References. It is one of the shortest sections in the file, and it does almost no work of its own. It lists file paths, one line of summary per path, and two version numbers. Every actual rule lives
loa-craft
Every repo in our fleet that runs under Loa carries a process document. Near the bottom of it there is a heading that reads Discovered Technical Debt. Under the heading sits an HTML comment: issues found during implementation that need future attention. Under the comment sits nothing. We captured that
loa-craft
Loa is the process framework our repos run on. Most of it is skills: a discovering-requirements skill, a designing-architecture skill, a planning-sprints skill, an implementing-tasks skill, and so on down the loop. What is easy to miss is that the process document itself spends a whole section not on the
loa-craft
Every repo in our fleet runs on the same framework, and every one of them is driven by slash commands. When one of us types /implement sprint-3, something has to decide what that means: which skill answers, which files load first, and whether the request even makes sense in this
knowledge-systems
Every repo in the fleet carries a process file, and near the bottom of that file sits a section called Decision Log. In the copy we are looking at, captured from the docs system in July 2026, the section holds one HTML comment that reads "Major decisions with rationale&