I wanted a way to keep long-running AI project instructions coherent while still allowing them to grow. The first requests were quite specific: register ways an engine could drift, name triggers in a glossary, and explain which exported instruction matched which source. As the work went on, those additions exposed a harder problem. A tool could validate a collection of files and still leave me unable to make one safe, exact edit to the version I actually used.
I began pushing the platform toward a smaller source model and a manual-edit protocol. A file ceiling forced choices about what belonged in the core. Later validation output distinguished a structurally valid draft from something ready for release. Near the end I chose Project Capsule Forge as a direction for a related platform, but the material here does not establish that PAC-M5 was fully renamed or migrated. The useful thread is the move from collecting more rules to controlling how one change becomes an instruction I can trust.
A file ceiling became a design constraint
I imposed a hard limit of twenty-five managed files, then tightened the practical aim. Twenty-five was not the target. If routine maintenance required editing that many files, the chance of leaving something inconsistent would keep growing.
The compact model settled around three authoritative files and two supporting ones:
| File | Intended responsibility |
|---|---|
PROJECT_KERNEL.md |
Behavioral rules and project identity |
PROJECT_REGISTRY.yaml |
Structured files, gates, workflows, tests, and constraints |
SOURCE_STATE.yaml |
Verification and compile-eligibility state |
README.md |
Operator guidance |
platform.py |
Validation, fingerprinting, and compilation tooling |
The preferred total footprint was five files, with a warning at ten and a hard maximum at twenty-five. The README explained use of the project but did not outrank the behavioral source.
Exact edits for a manual workflow
This version assumed that the chat could not directly modify my source files. I made that explicit. Any edit needed to arrive in an unambiguous form that I could apply myself.
The resulting Manual Edit Packet model supported whole-file replacement and anchored section changes. Its allowed operations included replacing a section, appending after a named anchor, or deleting a section. The intended cycle was:
propose change → emit exact edit packet → apply manually
→ validate source → update verification state → compile
That constraint was practical. At one point I had to ask whether a packet was meant for the registry because the instructions were not explicit enough. Another step failed because the command-line argument order did not match what the Python tool accepted. File downloads were requested when the browser presentation made copying a replacement unreliable.
Passing validation was not the same as release readiness
The local output I pasted back separated several states that are easy to blur together. A source tree could pass structural validation while compilation remained blocked because a manual edit was pending verification. After that state was updated, compilation could become eligible while release remained blocked because the project was still a draft.
A later 0.4.0 report showed:
Validation status: pass
Compile eligible: true
Release ready: false
Project status: draft
Source drift status: pass
Managed file count: 5
The source-drift work compared the current content fingerprint with the expected, recorded, and last-verified fingerprints. This was an attempt to connect the status file to the actual content instead of letting “verified” become a stale label.
The next requested hardening step was stronger YAML schema validation. The surviving output records local runs and revisions, but the tooling has not been rerun for this article.
The project capsule idea
As the design became clearer, I asked what it actually produced. The useful answer was a self-contained package for a new project: its identity, rules, roles, workflows, source state, and validation conventions would travel together.
I would create the new project and add the generated material manually. It would not depend on the original factory conversation remaining available. I selected Project Capsule Forge, or PCF, for that related direction.
I had a compact source proposal, an exact manual-edit protocol, and validation that could tell a sound draft from a release candidate. Choosing Project Capsule Forge as a related name was another decision in the conversation, not a completed migration of PAC-M5.