DEV Community: Vladimir Panov

Notes: Memory, Context, and Large Language Models (LLMs)

Vladimir Panov — Wed, 01 Jul 2026 05:24:54 +0000

Notes following a discussion on how memory works in language models - and how it could be improved: ranging from the common issue of "context window" exhaustion to node architecture and entity linking.

1. The illusion of an infinity chat.

No model possesses a truly infinite context; the window size is always finite. The illusion of a continuous dialogue is maintained through information compression and selection mechanisms. Specific approaches include: Infini-attention (from Google) - a compressed long-term memory mechanism built on top of standard attention; it reportedly maintains performance quality even when exceeding the million-token threshold. StreamingLLM - utilizing several "anchor" tokens at the start of the sequence combined with a sliding window for recent tokens. MemGPT/Letta - a system resembling OS virtual memory that incorporates three tiers: core memory (always within the context window), archival memory (in vector storage), and recall memory (the full history in a database). Mem0 - instead of summarizing everything indiscriminately, it selectively stores only significant facts, reducing token volume by 80–90%. Also worth mentioning is EM-LLM: this model segments history not mechanically, but based on a "surprise" metric - an approach that appears to mirror the workings of human memory.

2. Human memory as a working model of limitation.

Human working memory holds only a small number of items at once (the classic figure being Miller’s “magic number” of 7±2, which Cowan later revised to approximately 4). Yet, it is precisely this limitation that compels the brain to constantly compress information: what is stored in memory is not a recording, but a reconstruction. As early as the 1930s, Bartlett demonstrated that remembering is the recreation of an image based on cognitive schemas rather than the playback of a tape recording; this is why memory is prone to distortion, yet it is also what allows it to serve as a tool for thinking rather than merely an archive. Forgetting is not a data "leak" but an active process: during sleep, the hippocampus "replays" events and gradually transfers them to the neocortex in a generalized form (consolidation). This limitation is not a glitch but a factor that forces the system to generalize information rather than simply copying it.

3. Language, encoding, and the "cost" of memorization.

The brain doesn't store every word form individually. Instead, it performs morphological analysis (isolating the root and the rule), ensuring that a complex morphological system doesn't create "search noise" at the semantic level. However, this poses a problem for the tokenizers used in LLMs: for instance, the o200k_base tokenizer yields an average of 1.96 tokens per word for Russian, compared to 1.16 for English. Consequently, processing the same amount of information in Russian is approximately 70% more expensive, as the rich inflectional system causes BPE token frequencies to be "diluted" across dozens of forms of the same word. Notably, a comparative study of languages (Coupé et al., 2019) demonstrated that the rate of spoken information transmission tends toward a universal value - approximately 39 bits per second. Languages with high syllabic information density require a slower speaking pace; thus, there is no "free lunch" in this regard.

4. Thought and language are separate systems.

Using fMRI, Evelina Fedorenko (MIT) demonstrates that the brain's language network remains virtually inactive during the performance of mathematical and logical tasks, musical activities, or contemplation of others' intentions. Patients with severe global aphasia lose their language abilities yet retain the capacity to perform arithmetic, play chess, and reason about the world around them. A word is not a vessel for a thought but rather a label "attached" to it only after the thought has been formed. In bilinguals, this is corroborated by the Revised Hierarchical Model (Kroll and Stewart): there is a single conceptual node linked to distinct lexical units for each language. This explains the example involving the words "girl" and "девочка" (Russian for 'girl'): it is an image that surfaces in memory, not the word itself; the word is selected only subsequently.

5. A New "Language" of Memory: Writing and Reading Around the Text.

Two approaches directly address the question of exactly how writing to and reading from memory occurs - distinct from the prompting process itself.

The continuous approach: "gist tokens" (Mu et al., 2023) - the model is trained to compress the prompt into a set of vectors. This is not human-readable text but data read directly by the model (achieving compression ratios of up to 26x). Similar methods are employed by AutoCompressors and ICAE, utilizing summary vectors or memory slots. The Titans model (Google, January 2025) takes this further: long-term memory is implemented as a separate neural module (an MLP) that continues learning during inference, with "memorization" decisions based on a gradient-based "surprise signal" - a mechanism virtually identical to human memory consolidation.

The conceptual approach: Meta’s Large Concept Models (December 2024) - the model operates not on tokens but on "concepts": embeddings of entire sentences within the SONAR space, which is independent of both language and modality. A sentence in Russian, French, or Hindi yields a virtually identical representation; reasoning occurs at the concept level and is rendered into a specific language only at the output stage.

The symbolic approach: graph-based memory (Zep/Graphiti, Mem0’s graph mode) - during writing, the LLM autonomously extracts entities and relationships, while reading involves graph traversal rather than vector search. Although less efficient in terms of data compression, this method allows humans to read and edit the memory content.

The trade-off for using approaches based on continuous representations lies in their interpretability: they cannot simply be "opened and read". Individual facts within them cannot be corrected in isolation, and, as a rule, they are tightly coupled to a specific model.

6. The uniqueness of interior spaces and the problem of coordination.

If two models form their internal representations independently, there is no guarantee that these representations will align - a phenomenon that has already been studied empirically. In the game Hanabi, agents that play brilliantly alongside the partner with whom they trained perform extremely poorly when paired with an independently trained agent. During joint training, they develop arbitrary conventions - or "handshakes" - unlinked to the objective values of the cards; this phenomenon is known as the zero-shot coordination problem. The "other-play" method enables agents to avoid such idiosyncratic traits to ensure compatibility, though this comes at the cost of reduced flexibility and uniqueness.

There is also an opposing view: the Platonic Representation Hypothesis (Huh, Isola et al., ICML 2024) posits that as models scale up and the tasks they perform become more diverse, their internal representations don't diverge; instead, they converge toward a unified statistical model of reality - since they are all modeling the same world. Furthermore, a technique utilizing relative representations (Moschella et al., 2023) demonstrates that even formally incompatible latent spaces can be aligned without retraining. This is achieved by comparing the degree of similarity to a fixed set of reference points (anchors) rather than comparing absolute coordinates. In other words - the task becomes one of recognizing different orientations of the same underlying geometric structure, rather than performing a word-for-word translation.

7. Subjective, objective, and the nature of "glitches".

A category such as "cat" is not an objective entity but a culturally shaped interpretation. Eleanor Rosch’s prototype theory demonstrates that concepts are organized around a "fuzzy" prototype rather than having rigid boundaries. Individual deviations (such as a fear of cats) are not "bugs" but the result of the system tuning itself based on personal experience.

The way we explain someone else's deviation (e.g., "a cat must have scared him in childhood") reflects the work of what Gazzaniga called the "left-brain interpreter" - a specialized brain module that constantly generates plausible explanations for behavior, even without access to the true cause (recall the classic split-brain experiment involving images of a chicken claw and a snowy landscape). This is a normal mode of brain function, not a malfunction.

An analogy can be drawn to Large Language Models (LLMs) based on the OpenAI paper "Why Language Models Hallucinate" (Kalai, Nachum, Vempala, Zhang; September 2025). The paper formally proves that any model capable of generalizing beyond its training data will inevitably either hallucinate or "collapse" by refusing to provide diverse answers - there is no other way. The situation is exacerbated by the fact that training and evaluation processes reward confident guesses rather than an honest "I don't know." An important caveat: this strips the term "glitch" of its moral baggage but don't erase the distinction between subjective categories (where there are no wrong answers) and facts (where reality is singular, and confidence calibration matters regardless of the mechanism).

8. How this actually gets built: RAG today.

The standard pipeline as of 2025-2026 looks like this: data chunks (typically 512-1024 tokens) are fed into a vector store that supports similarity search (using HNSW indices). Since pure vector search is unreliable when dealing with specific facts and names, a hybrid approach has become the standard: combining embeddings with the BM25 algorithm and merging results via Reciprocal Rank Fusion (RRF). Next, a cross-encoder (a re-ranking model) steps in to select the most relevant candidates from a pool of fifty (boosting accuracy by approximately 17%). The major trend of the past year has been "agentic RAG": instead of the system pre-determining what information to retrieve, the LLM itself formulates the query, evaluates whether the retrieved data is sufficient, and repeats the search if necessary.

Anthropic has already implemented this solution in a real-world setting - it is not merely a concept: Claude.ai summarizes chat history daily, extracting key facts that are carried over into new conversations (with each project maintaining its own isolated memory). At the API level, a memory management tool is available: the model autonomously creates, reads, and updates files in persistent storage that survives across sessions, loading only the necessary data as needed without overloading the context window.

9. An entity graph built on the fly.

The Zep/Graphiti architecture embodies a working prototype of the model where "a node is created upon the first interaction, while edges accumulate through repeated interactions". It comprises three levels: episodes (raw observations), entities (extracted entities, deduplicated across sessions), and communities (clusters of related entities). Upon receiving new data, the LLM determines whether the information refers to an existing node (an update or expansion) or a new one (creation) - a decision made not based on a rigid distance threshold, but through contextual assessment. Each edge is annotated with bitemporal metadata - information indicating when the fact was true and when the agent acquired the data. Without this, the node would eventually accumulate contradictory edges and become useless.

The linking problem itself represents the classic stability-plasticity dilemma - a challenge around which Carpenter and Grossberg built an entire architecture in the 1980s: Adaptive Resonance Theory. This theory employs a vigilance parameter (ρ) that dictates how closely a new stimulus must match an existing node to trigger an update rather than the creation of a new node. A setting that is too loose leads to the merging of distinct entities and node distortion, while one that is too strict causes a single entity to spawn fragmented duplicates. There is no universally correct threshold.

A biological parallel to this three-stage model is the Complementary Learning Systems theory (McClelland, McNaughton, & O'Reilly, 1995): the hippocampus rapidly encodes each episode individually (employing pattern separation to preserve detail), whereas the neocortex slowly integrates these episodes into a generalized semantic node through repeated replay during sleep.

10. A node as a response, not an image.

A key shift lies in the fact that a node is defined not by the stimulus itself, but by the convergent pattern of response to it; this approach is characteristic of functionalism in the philosophy of mind and is supported by direct empirical evidence. Examples include "concept cells" - such as the so-called "Jennifer Aniston neuron" (Quiroga et al., Nature, 2005) -neurons in the human medial temporal lobe that activate upon perceiving a specific individual, regardless of the information channel: whether through various photographs, a written name, or even a name spoken by a computer-generated voice. A similar phenomenon was artificially replicated in the CLIP model (Goh et al., OpenAI, 2021), where a "Spider-Man neuron" responds to a photograph of a spider, the word "spider," or an image of the Spider-Man costume; the authors explicitly state that they were inspired by Quiroga’s discovery.

The "signal flow → weighted network → node key" mechanism closely resembles the VQ-VAE architecture (Van den Oord et al., 2017): an encoder transforms a signal into a vector, which is matched to the nearest element in a learnable discrete codebook, yielding a discrete index as output, while the codebook itself continues to learn during operation. A historical precedent for the concept of "space reorganization during sleep" is the wake-sleep algorithm (Hinton, Dayan, Frey, Neal, 1995), which incorporates a distinct "sleep" phase: the network generates its own data (in a top-down direction) to adjust weights offline.

Individual elements of this picture already exist and have been validated. The open engineering question lies not in any single one of them, but in how to combine them into a unified, continuously functioning structure, rather than a system fixed at the pre-training stage.

Key sources

AI-Native Software Delivery

Vladimir Panov — Sun, 10 May 2026 04:43:15 +0000

A process for shipping software when AI generates most of the implementation and humans own intent, validation, and behavioral guarantees.

This is a rewrite of an earlier article that introduced the idea. The thinking has matured into a working, clone-and-go process toolkit:

github.com/DominicTylor/ai-software-process

What follows is the methodology in its current shape — what changed since the first article, why those changes mattered, and what the resulting process looks like in practice.

The problem this process exists to solve

AI now generates a meaningful share of production code, and that share keeps growing. Engineers spend less time writing code and more time reviewing what was generated, often less deeply than we like to admit. The question stops being "is this code well-written?" and becomes "does this code do what we said it should do?" — and the systems most engineering teams use today were designed for a world where humans wrote everything by hand.

A few pains, all interlocking:

Story trackers describe intent in plain English in one place; the code that implements it lives somewhere else; the tests that verify it live somewhere else again. Each drifts at its own rate. A Jira ticket that was current six months ago describes behavior that the code no longer has — and nobody knows when it stopped being accurate.

BDD frameworks tried to bridge this. They duplicated scenarios in Gherkin (.feature files) alongside the executable code. Two artifacts that say the same thing must be kept in sync, and they never are. The feature file becomes documentation; the code becomes the truth; the gap between them is where bugs live.

Decision history fragments across chat threads, old tickets, deleted documents, and the heads of senior engineers. When a new contributor asks "why did we drop password authentication?", the answer is gone. The current code shows what we do; nothing shows why.

Tests check internal state — Redis keys, database rows, in-memory variables — instead of customer-observable behavior. They pass while the user-visible flow is broken, because they were written to be easy rather than honest.

And underneath all of this: when AI generates the implementation, none of the safeguards a team built around human authorship apply the same way. Code review catches less because reviewers skim more. Linters and type checks don't catch semantic drift from the spec. The acceptance criteria — if they exist — are in a ticket nobody reads.

The standard practices were designed for a different world. The reshape is not a productivity tweak; it is a structural change in where trust lives.

What changes

Implementation-centric engineering optimized for the people writing code. Result-centric engineering optimizes for the property the product must hold. The shift is concrete:

Humans increasingly own intent, validation, and behavioral guarantees. AI increasingly generates the code that satisfies them. The center of human attention moves from "did I write this well?" to "have I described what must hold, and is it verified?"

This is not a productivity argument. The argument is that as AI-generated code becomes the default, the only durable form of trust is executable behavioral validation: a machine-checkable through-line from customer intent to verified behavior. Everything in the process below serves that through-line.

Stories are folders, not tickets

The unit of work is not a row in a tracker. It is a folder in git.

stories/auth/user-signup/
  user-spec.md           ← what the user wants, who they are, what must hold
  e2e/
    signup-via-github.spec.ts
    signup-via-magic-link.spec.ts
  perf/                  (optional)
  security/              (optional)
  a11y/                  (optional)

The user-spec describes intent, personas, high-level user goals, functional constraints, architect tech notes, quality-gate notes, scenario references, and which platform invariants the Story is subject to. What it deliberately does not contain: step-by-step scenarios in prose (those are in the commented tests), changelogs (in git), resolved-question annotations (in git), future-state plans (elsewhere), implementation choices (in tech specs in code repos).

A Story always describes current behavior — not history, not roadmap, not the journey of how it got here. If the system behaves this way right now, it goes in the spec. Otherwise, it goes elsewhere. That single rule eliminates a class of drift that older spec formats accept by default.

A scenario, concretely

Acceptance criteria live as commented executable tests:

test('User signs up via GitHub for the first time', async ({ user }) => {
  // # User opens the signup page
  await user.opensSignupPage();

  // # User sees three auth options with GitHub marked as recommended
  await user.seesAuthOptions({ recommended: 'github' });

  // # User clicks "Continue with GitHub"
  await user.clicksContinueWithGitHub();

  // # System completes OAuth and lands the user on an empty workspace dashboard
  await user.expectsDashboardWithEmptyWorkspace();
});

The Owner writes the comments first. An AI helper, or the Implementer, fills in executable code under each comment without removing it. The comment stays as documentation; the code stays as verification; they live in the same file for the life of the test.

Three properties fall out of this shape with no extra effort:

The Owner reads only the comments to verify acceptance criteria. The Quality Gate Specialist reads comments and code together to verify they agree. Drift between described behavior and verified behavior is physically impossible — they share a file and appear in the same diff. There is no second artifact to keep synchronized.

A scenario that has only comments and no code under them is wrapped in test.todo(). It appears in the test runner as TODO. The Story's observable state — what's drafted, what's verified, what's still pending — is whatever the test runner reports. Not a status field; the report.

Frameworks as bilateral contracts

Notice the test above. No selectors. No data-testid strings. No sleeps. No mocks. The verbs — user.opensSignupPage(), user.clicksContinueWithGitHub() — come from a framework owned by the Quality Gate Specialist.

The framework's PageObjects hold one end of a bilateral contract:

// frameworks/e2e/page-objects/login-page.ts
class LoginPage {
  async entersEmail(email: string) {
    await this.page.fill('[data-testid="login-email"]', email);
  }
}

The test-id "login-email" lives in this file, in plain code. Code-perimeter implementation reads this file to know what the UI must expose. There is no separate test-id registry; the framework's PageObjects are the registry.

When the Story uses user.entersLoginEmail(...), the framework declares that the UI must render data-testid="login-email" on the login form's email input. The code-perimeter team reads the framework to know what to build. The team building the test reads the framework to know what verbs are available.

Same pattern for other frameworks. A probe.scanTable('account', { where: 'password IS NOT NULL' }) call in the security framework rests on a database probe helper that names the table and column explicitly; code that creates the schema reads that helper to know what names are expected.

This is the through-line from intent to verified code: scenarios consume framework verbs, framework PageObjects declare identifiers, code-perimeter implementation honors those identifiers. The contract is not implicit. It is readable code on both sides.

Constitution: platform-wide invariants

Stories describe features. Some rules apply across all features — they are invariants of the platform, not properties of any one Story. Those live in a separate constitution.md document at the repository root.

A constitution is short, prose, self-contained:

No user password is ever stored, transmitted, or accepted by any code path.

The SMTP capture service never originates outgoing connections on ports 25, 465, or 587.

No request authenticated by tenant A can read or modify data belonging to tenant B. Cross-tenant access attempts return 404 or 403, never 500 and never partial data.

All persistent data is encrypted at rest under platform-managed keys.

The constitution declares; it does not enumerate enforcement. Each rule has an owning Story under stories/ — same shape as any other Story, but with an attacker or system-probe persona, scenarios that attempt to violate the rule, and assertions that the violation is refused.

A Story may reference a constitution rule it depends on (enforces: no-passwords in frontmatter) for traceability. The constitution itself does not reference back. It does not need to know how each rule is verified or by which Story.

The Architect holds final word over constitution.md. When a Story's design would conflict with a rule, the Architect-review skill blocks the PR. If the team genuinely wants to change the rule, that goes through a separate constitution PR — explicit, reviewed, recorded.

Decision history in commit messages

Every behavioral change in the system is captured in a structured git commit message:

behavior: drop password auth from auth flow

Why: minimize attack surface; password storage adds risk for a developer-tool
audience that is comfortable with OAuth and magic links.
Considered: keep with bcrypt, move to passkeys only, drop entirely.
Chose: drop entirely; OAuth + magic link cover all signup and login paths.
Affects: stories/auth/user-signup/, constitution.md §3.2.

A commit-msg git hook enforces the Why / Considered / Chose / Affects shape on every commit whose subject starts with behavior:. Non-behavioral commits (chore, fix, docs) are not gated. The hook is local; a matching CI check protects main against commits that bypassed the hook.

Significant decisions are tagged for direct addressability:

git tag decision/no-password-auth <sha>
git tag -l "decision/*"

To answer "why did we decide X?", the workflow is git log --grep="X", follow tags, read the structured sections of the relevant commit. There is a /decision-search skill that makes this queryable in natural language, but the storage layer is just git.

This rule has one specific consequence: no artifact in the repository contains a changelog. No "Resolved on 2026-05-11" annotations inside specs. No version-history blocks. Specs describe current behavior. The history of why behavior is current lives in commit messages, addressable through tags.

State is observed, not declared

A Story is not a thing that has a status: "approved" field. The tracked unit is a change vector — a (branch, PR) pair against the master repository — and its state is whatever git and the forge say it is.

Branch	PR	Vector state
Doesn't exist (or merged into main)	—	Doesn't exist, or is live
Exists, no PR	—	Private work in progress
Exists, PR open (any state)	Draft / Open	In review or iteration
Exists, PR open, all approvals + CI green	Open	Ready to merge
Merged	Merged	Live

There is no status field anywhere. No external state store. git branch -a plus the forge's PR list answers "who's working on what, what's in review, what's blocked, what just shipped" — without a separate tool.

Parallel work follows from this naturally. Multiple branches mean multiple vectors in flight. Two vectors touching the same area are a coordination signal — usually a sign that two people are attempting the same change without realizing it. Tooling on top of the process (a dashboard, a query) can surface this; the process itself does not block it.

Master and code perimeters: asymmetric awareness

A non-trivial project usually has two physical territories: the master repository where Stories, frameworks, and constitution live; and one or more code repositories where implementation, tech specs, and code review live. In small projects these can coexist in one physical repo; the boundary remains conceptual.

Awareness flows in one direction only.

The master perimeter never queries, inspects, or coordinates with code repositories. Its references to them are descriptive ("this Story affects services A and B"), not operational. A skill running in the master perimeter never opens a code repository's pull request list, never reads code-side tech specs to decide what to do, never coordinates code-side merges.

The code perimeter, in contrast, reads the master perimeter as its source of truth. To produce a tech spec or implementation, an engineering agent in a code repository reads the corresponding Story's user-spec, the architect tech notes inside it, the quality gates, the constitution rules it must respect, and the framework's PageObjects to know what identifiers to expose.

This asymmetry keeps responsibilities clean. The master perimeter never has to know about deployment topology, CI runners, or how many code repositories the company has. The code perimeter never has to argue with product about what a feature should do.

Roles as areas of final word

The process names six roles: Owner, Architect, Quality Gate Specialist, Implementer, Code Owner, UI/UX Specialist. These are responsibilities, not positions. In a one-person project, one human holds all six and switches modes consciously. In a fifteen-person team, they tend toward distinct people. The role structure stays the same regardless of headcount.

Stories are written collaboratively. Anyone with something to contribute writes into the Story — Owner sets intent, Architect adds tech notes, Quality Gate Specialist refines scenarios, UI/UX Specialist adds accessibility constraints. A Story does not "belong" to a role.

What roles hold is areas of final word — domains where, when a decision is contested, that role's approval is required to ship. These are enforced through CODEOWNERS rules on path patterns, not through social convention. Owner over stories/**/user-spec.md, Architect over constitution.md, Quality Gate Specialist over frameworks/** and scenario folders, and so on.

A second pattern governs how non-final-word roles still carry real weight: mandatory review with required engagement. Horizontal roles — Architect, Quality Gate Specialist, UI/UX Specialist — review every relevant Story automatically. Their comments are blocking. The Owner is free to overrule their advice in the Owner's own product domain, but only by explicit acknowledgment — a written statement that the risk is read, accepted, and carried. Silent dismissal is not allowed.

When a horizontal role believes an Owner's acknowledgment underestimates a systemic risk, the open path is to escalate by opening a constitution PR. The discussion moves from Story scope (Owner's call) to platform scope (Architect's call). The right argument resolves at the right altitude.

Skills and sub-agents

Skills are AI-assisted helpers — focused operations a contributor invokes like commands: /spec-brainstorm, /architect-review, /scenario-implement, /decision-search. Sub-agents are role-specialists with deeper expertise in a single domain (spec-spec for product consistency, architect-spec for constitution and system invariants, quality-spec for frameworks and coverage, ui-ux-spec for visible-state completeness, decision-historian for git history). Skills invoke sub-agents when judgment in a domain is required.

The operational principle is: skills are soft assistance inside a branch, hard gates on the pull request. While work is private, every skill is invokable and ignorable. An author can use them or not. Once a PR is opened, the horizontal-role review skills run automatically and their comments are blocking. Resolution takes one of two forms — fix the concern, or write an explicit acknowledgment of the risk. There is no third option.

This separation matters. A contributor who prefers to write everything by hand is not punished. A contributor who relies heavily on AI is not given a shortcut around the gates. The path is different; the destination is the same.

What this process is not

To prevent drift toward familiar models:

Not Jira-as-spec. A Story is not a ticket. Stories live in git and always describe current behavior. There is no parallel ticket queue describing the same work.

Not BDD with Gherkin. Scenarios are first-class TypeScript inside test files, not a parallel .feature layer that has to be kept in sync. One source of truth.

Not test-after. Acceptance criteria are written before or alongside implementation, as commented executable tests. Code is generated to satisfy them, not the other way around.

Not waterfall, despite the milestone names. Stages cycle. Implementation can expose gaps in scenarios; review can redirect back to spec. The process recognizes legitimate return points instead of pretending the flow is linear.

Not vendor-locked. The methodology shape is independent of any specific AI tool. The current incarnation uses Claude Code; the same shape works with any AI environment given equivalent primitives.

Not headcount-prescriptive. Roles are responsibilities. One person can hold all six. A team of fifteen can split them across people. The process does not require any specific organizational chart.

Where to start

The process lives at github.com/DominicTylor/ai-software-process.

The repository is a clone-and-go Claude Code toolkit. process.md is the full canon. constitution.md is a working template adopters rewrite in place. templates/story/ holds the per-Story scaffolds skills consume when creating new artifacts. .claude/skills/ and .claude/agents/ ship a complete master-perimeter toolkit (twelve skills, five sub-agents) plus a code-perimeter starter pack drawn from a real TypeScript/Node monorepo. .githooks/commit-msg enforces the structured commit format locally; .github/workflows/ enforces it (and spec validation, and ai-review) on the PR.

Adopt by forking, rewriting the constitution and high-level project description in place, and piloting a Story end-to-end. MIT No Attribution license — no permission, no obligation to credit, no friction. Attribution back is appreciated but never required.

If anything here resonated, that's where it goes from idea to applied.