One idea, applied across the system.

The thesis, stated first

The system starts with a simple rule: do not rely on an agent to remember every boundary. Build the boundary into the workflow.

A safety rule written in a prompt is useful, but it is still a soft guard. If the model has access to a tool, it can still try to use it. When the cost of a mistake is high, the safer design is to remove the unsafe option entirely or put it behind a human approval step.

Make the safe path structural. Do not depend on perfect behavior when the system can be designed to prevent the wrong action in the first place.

The starting point

The first version of the framework came from a practical need: turn repeated process decisions into reusable configuration for an AI coding workflow. That meant defining specialist roles, reusable capabilities, behavioral rules, and project settings that an agent could use without rediscovering the same context every session.

The goal was not to make the system more dramatic. It was to make it more dependable. A new session should be able to understand the role it is playing, what tools it has, what it owns, and where it needs to stop.

Four decisions that set the shape

The configuration directory became the source of truth. Working notes in a separate store created too much risk of drift. The rules an agent reads should live where the agent reads them, so the configuration directory became the version-controlled home for the framework.

The filesystem stayed flat, but the logic stayed organized. Testing showed that nested role folders could be missed by the coding agent. The solution was to keep storage flat while using metadata to define divisions, roles, and relationships. The org chart is generated from that metadata.

Capabilities and roles have to agree. Every specialist capability declares which roles can use it. Every role declares which capabilities it carries. If those two sides disagree, validation fails. This prevents orphaned capabilities and keeps roles from quietly absorbing too much responsibility.

Bloat became measurable. A role can only carry so many capabilities before it becomes too broad. The framework uses numeric thresholds to warn or fail when a role grows past a reasonable size. What used to be a judgment call became something the system can check.

What this established

The first version of the framework created the base structure: specialist roles, reusable capabilities, behavioral rules, decision records, and a validator that checks the relationships between them. Everything built after this follows the same pattern: make the workflow explicit, validate it, and avoid relying on memory where structure can do the job.

The problem this solves

As the system grew, a pattern kept showing up: new sessions had to rediscover old decisions. That wasted context and created room for mistakes.

Carrying entire transcripts forward was not the answer. Full transcripts are too large, too noisy, and too hard to reuse cleanly. The better approach was to separate what every role should always know from what only matters in a specific situation.

Layer one: rules that load when needed

The first layer is made of task-specific rules. Each rule describes a recurring procedure: when this kind of work appears, follow this process.

Those rules are not loaded every time. They declare triggers, and the relevant rule loads only when the current task matches. That keeps the session focused and avoids flooding every task with context it does not need.

The rules cover recurring hazards: documentation quality, discovery conventions, migration safety, and where different kinds of outputs should live.

Layer two: principles that are always present

Under the task-specific rules is a smaller set of always-loaded principles. These are not step-by-step instructions. They are the posture every role shares.

Verify before guessing. Treat documentation as part of the deliverable. Keep scope narrow. Be conservative by default. Surface uncertainty instead of pretending. Keep humans involved on irreversible actions.

The point is to give every session the same baseline without forcing every session to carry every detailed procedure.

How the two layers work together

Procedure belongs in the trigger-based rules. Posture belongs in the always-loaded principles. Cross references connect the two so a session can find the right level of detail when it needs it.

This keeps the system consistent without making it heavy. A role starts with enough context to behave well, then loads the deeper process only when the task calls for it.

The gap this closes

Once the framework had roles, rules, and shared principles, the next problem was improvement. The system needed a way to notice recurring issues across sessions and turn them into better process without letting the agent rewrite its own guardrails.

That distinction matters. A system that can observe patterns is useful. A system that can permanently change its own rules without review is a risk.

The two pieces

An append-only observation ledger. One file captures recurring observations in a small, fixed format. Each entry includes a recurrence key, type, target tier, scope, status, and short note. The ledger is meant to capture patterns, not sensitive data.

A curator that proposes, and only proposes. A dedicated role reads the ledger, groups related observations, counts recurrence, and produces a proposal when a pattern is strong enough. If the pattern is not strong enough, it reports the count and stops.

The important boundary

The curator cannot write rules, edit files, run shell commands, or dispatch other roles. It can read and produce a proposal. That is it.

The learning loop can surface what should change, but it cannot make the change permanent by itself.

The full path has three steps: observations accumulate, the curator proposes, and a human reviews the change before a separate writer persists it.

Why the friction matters

This adds friction on purpose. Even an obviously useful improvement still needs review because deciding what becomes permanent is a judgment call. The learning loop makes the system better without giving it unchecked authority over its own rules.

Where the story arrives

The next improvement was not about adding more power. It was about reducing friction without removing control.

By this point, work across projects required too much manual setup. Cross-project tasks had to be assembled by hand, some smaller projects were not routable from the top-level system, and repeated commands were creating unnecessary overhead.

The goal was to make routine work easier while preserving two constraints: no raw metered API keys, and human approval for actions that cannot be undone.

The friction work

• Commit-only auto-save. Automatic push was removed. A local commit can be reviewed and reversed. A push changes the remote and should require a person.
• Thin orchestrators for smaller projects. Even minimal projects were given a lightweight route into the same top-level workflow, so the system could stay consistent without forcing every project to become large.
• A one-command front door. Cross-project work can be started from a single entry point. The command resolves scope from a static table, refuses unsafe shortcuts, and keeps approvals enabled.

The line that will not be crossed

The design rule is simple: automate the reversible, gate the irreversible.

A scheduled unattended routine for irreversible work was rejected because it would remove the approval step and create pressure to use the wrong authentication model. That kind of convenience is not worth the risk.

The gate in practice

The system ended with less friction, not less oversight. Routine work became easier to start. Local commits stayed local for review. The action that changes the shared world still waits for a human decision.

The framing

This site documents private engineering work without exposing private project details. That is not just a written promise. It is part of how the publishing workflow is designed.

Publishing is one of the highest-risk actions in this system because a leaked identifier on a public page cannot be taken back. The safer approach is to separate private source material from public-facing content before anything reaches the site.

The single reader

Exactly one role can read raw private sources. That role produces sanitized drafts in a staging area. Everything downstream works from approved summaries, not the raw source material.

The boundary is enforced through tool access. The reader can read and write only where it is supposed to. It does not get broad shell access, network access, or the ability to dispatch other roles.

If a source names something that has no approved public alias, the role emits nothing for that component. A missing mapping is a blocker, not an invitation to guess.

Defense in depth

Three checks back up that seam:

• Default-deny publishing. New artifacts are treated as unsafe until they are explicitly classified.
• A build-time denylist. Forbidden terms are checked alongside structural patterns like private paths, repository URLs, and personal identifiers.
• An independent pre-publish scan. A second check looks for leaks the first pass might miss.

Go-live remains a human decision. No agent deploys or pushes the public site silently.

The same posture, extended

The same approach applies to new tools and commands. External tools are brought in deliberately, pinned, and checked rather than copied casually. Draft-improvement commands can inspect and suggest changes, but they do not rewrite or execute without opt-in.

The point

This site is not only describing the framework. It is using the framework. The publishing workflow keeps private source material separated, validates the output, and leaves the irreversible step behind a human approval gate.