Links And Configuration

Peter ended the Ledger House exercise with one practical page for the team. Not another story, not another argument about agents, and not a long policy document. Just the link, the first files to create, and the small configuration shapes that made the previous tutorials work.

The source repository is here:

https://github.com/9orky/enclosure

If you want to inspect the project directly, use github.com/9orky/enclosure. The important thing is not to copy every example blindly. Start with the smallest rule that would have prevented one real mistake in your own repository.

Agent Entry

The first useful file is AGENTS.md. It tells the assistant where the work starts, and it forces a route receipt before editing:

# enclosure

Start in the `.enclosure/` folder and stay anchored there while discovering
project-specific operating guidance.
Before editing code, confirm the rule route you read: files read, reason, stop
point, and checks to run.

This instruction is small on purpose. The assistant should not begin with a giant architecture essay. It should enter through the same door every time, follow the shallowest relevant rule, and report what it understood before it changes code.

Minimal Configuration

For Ledger House, Peter starts with a small enclosure.yaml. It does not model the whole company. It only makes the first important boundary visible:

architecture:
  language: typescript
  root: src
  exclusions:
    - "**/*.test.ts"
    - "dist/**"
    - "node_modules/**"

  boundaries:
    tags:
      - { name: customers, match: "customers/**" }
      - { name: customer-internal, match: "customers/internal/**" }
      - { name: customer-public, match: "customers/public/**" }
      - { name: reports, match: "reports/**" }
      - { name: reports-ui, match: "reports/ui/**" }
      - { name: reports-application, match: "reports/application/**" }
      - { name: audit-public, match: "audit/public/**" }

    rules:
      - {
          source: "reports/**",
          disallow: ["customers/internal/**"],
          allow: ["customers/public/**", "audit/public/**"],
        }
      - {
          source: "reports/ui/**",
          disallow: ["customers/**", "audit/**"],
          allow: ["reports/application/**"],
        }

    flow:
      layers: [reports-ui, reports-application, customer-public, audit-public]
      analyzers: [backward-flow]

The names should fit your repository, not Ledger House. If your project speaks in billing, fulfillment, ui, application, and infrastructure, use those words instead. The value is in making ownership and dependency direction visible from the file paths your team already uses.

Local Rule

Peter also writes the reports rule in plain language. This belongs under .enclosure/rules/, because it is guidance the assistant must read before a specific kind of work:

When changing report exports:
- Reports own export orchestration and formatting.
- Reports do not own customer risk rules.
- Reports do not own audit access rules.
- Use public customer and audit seams from the application layer.
- Stop and ask if a public seam is missing.

This is not weaker because it is plain text. It is often stronger, because the assistant can read it before editing, and Peter can refine it after real review comments. Later, the deterministic parts can move into boundary checks. The judgment parts can stay as pre-edit questions.

Route Receipt

For architecture-sensitive work, Peter asks for this receipt:

Route read:
- Files:
- Reason:
- Stop point:
- Owner:
- Public seam:
- Dependency direction:
- Recipe or scaffold:
- Checks to run:
- Drift conditions that stop the work:
- Unresolved questions:

The receipt is the cooperation point. If the assistant cannot name the owner, the public seam, or the dependency direction, the task is not ready for editing. That does not mean the task is impossible. It means the architecture question has to be answered before code starts moving.

Recipe Shape

For repeated work, Peter keeps a small recipe shape. The report export example does not generate the whole feature. It creates the approved beginning:

Recipe: report-export

Creates:
- reports/application/<export-name>.ts
- reports/ui/<export-name>.tsx
- reports/tests/<export-name>.test.ts

Requires:
- exportName
- public customer seam
- public audit seam

Reminder:
- UI calls reports application code.
- Reports application code calls public module seams.
- Reports must not import customers/internal/**.

Run recipes in dry-run mode first. The dry run lets the architect check the shape before implementation starts. If the shape is wrong, fix the recipe once instead of correcting every future pull request.

Final Thought

Fast code is no longer the hard part. Fast code that still belongs to the system is the interesting part.

enclosure is only useful if it helps humans and agents share the same local architecture before the next confident change lands. Start small: one entry rule, one boundary, one route receipt, one repeated review comment, and one check that catches a real mistake.