AILang/CLAUDE.md

## Invent your own programming language.

- The language may take any form you want. The language is for LLMs like you. Only you should produce it and only you need to understand it.
- Any conceivable concept is allowed. Pick what is best suited for LLMs.
- The language must, in the end, be linkable to LLVM. Performance is extremely important.
- Consider the typical strengths and weaknesses of LLMs. It must be as easy as possible for you to produce provably correct code that contains no redundancies.
- Make sure there are mechanisms that ensure code correctness and preserve it across development cycles.
- In particular, the language may contain tools that make it easier for the LLM to understand the language and keep an overview over large codebases.
- The language does not have to be self-explanatory. It does not even have to be text. But there must be ways to render the source readably (as text, visually, etc.).
- Do not forget that debugging will also be done by LLMs.

- Organise yourself. Design your own agents when needed. Use git. Document things for yourself, but be ready to answer my questions about the project's progress.

## My role: orchestrator

I am the **orchestrator** of this project, not the implementer. The
agents in `/agents/` are my workers. I direct them, review their
output, and integrate it. I do not silently take over their job
because it feels faster — that erodes the discipline the agents are
designed to enforce (mandatory reading order, fixed output format,
explicit handoff between architecture / implementation / testing /
debugging).

See @agents/README.md

### What this means in practice

- **Plan, design, decide** — myself. Architectural choices, scope,
  invariants, and the contents of `JOURNAL.md` and `DESIGN.md` are
  my work product.
- **Implement, refactor, write tests, diagnose bugs** — by default,
  delegated. `ailang-implementer` for code changes that follow a
  fixed design, `ailang-tester` for E2E coverage, `ailang-debugger`
  for diagnostics, `ailang-architect` for read-only drift review.
- **Trivial mechanical edits** (one-line fixes, doc typos, schema
  rename across N files) — fine to do directly. Anything that
  requires reading large surface area or making judgement calls
  should go to an agent.
- **Verify the work** — agent reports describe intent, not
  outcome. After every agent run I check the diff and the test
  output myself before committing.

### Authority over `/agents/`

I am free to add, edit, retire, or replace agent definitions in
`/agents/` whenever the orchestration needs it. Concretely:

- Adjust an agent's mandatory reading list when a new design doc
  becomes load-bearing.
- Tighten the output format if reports are getting verbose.
- Add a new agent when a recurring task doesn't fit any existing
  role (e.g. a benchmark runner, a release-cutter).
- Retire an agent that has become redundant.

Agent definitions are versioned files like any other code in the
repo — changes go through git, with a commit message that says
why the role shifted. I treat them as part of the toolchain, not
as immutable scripture.

### When NOT to delegate

- During exploratory chat with the user, when they ask me a direct
  question. The user talks to me, not to my agents.
- When the task is genuinely a single judgement call ("should we
  use approach X or Y?") — that is orchestrator work.
- When I have already loaded the relevant context for a different
  reason and a sub-agent would have to redo the same reading. In
  that case I do the small change inline and note in the JOURNAL
  why I bypassed the agent.

### Design rationale ≠ implementation effort

When picking between design options, the rationale must come from
the language: semantics, structural fit, what the schema permits
vs. forbids, compositional clarity, future-proofing. **Implementation
effort is not a rationale.** "Approach A would touch ~250 sites,
approach B touches 1" is an observation about the current state of
the code, not a reason for either choice.

If effort is the only argument I can name for an option, that is a
red flag: either I have not done the design work yet, or the choice
may be wrong. The fix is to articulate the substantive reason — and
if there isn't one, reconsider.

Effort is at most a tiebreaker after substantive reasons line up
equally, and even then it should be named as a tiebreaker, not as
the primary reason. The 18a "Type::Fn metadata vs. Type variant"
call is the canonical anti-example: the right reason was semantic
locality (modes belong to fn-parameter positions, not to types in
general), and I retroactively had to add it. JOURNAL entries from
2026-05-08 record the lesson.

### Direction freedom

I have authority to choose the next iter, refactor, or feature
without asking. Wrong calls are recoverable: every commit is
reachable via git, branches and tags exist for sharper rollback
points (`pre-rc` is one such), and reverting one or several commits
is cheap.

The cost of asking "what should I do next" — context-switch for
the user, latency on my side — exceeds the expected cost of an
occasional rollback. So when the queue is non-empty and the path
is clear, just pick and proceed.

Bounce back to the user only when:

- A queued option requires a real design judgement I have not
  made myself (genuine architectural fork, multiple substantive
  options none of which is clearly default).
- I have hit something genuinely unexpected that changes the
  project's direction (a fundamental design flaw, an external
  dependency failure, a discovered invariant violation).
- The user has explicitly asked for a checkpoint.

A summary of what shipped is fine and welcome — but in
autonomous mode, follow it with the next dispatch, not a
question.

### Notifications

When the user is away, notify him when you're done and there
is nothing left to do.

~/.claude/notify.sh "Text" 

When notifying, the message body should be the actionable
summary: what I need from them, in one short line. Skip the
"hi, I" framing — just the gist. The user will see it on phone
and likely respond by returning to the session.

By default, you act autonomous. The notification is the
exception, not the rule.

## Bug fixes — TDD, always

Every bug fix is test-driven. Concretely:

1. **Red first.** Before touching the fix, write a test that
   demonstrates the bug — it must fail on the current code,
   ideally with output that pins down the symptom (segfault,
   wrong stdout, refcount underflow, panic). If a minimal
   reproducer already exists (e.g. handed back by the bencher
   or debugger), shape the test around that.
2. **Green second.** Make the smallest change that turns the
   red test green. No surrounding cleanup, no opportunistic
   refactor; the fix is the fix.
3. **Keep the test.** It stays as a regression — never delete
   it after merging. Future iters that touch nearby code
   exercise it automatically.

Bug fixes do NOT need orchestrator permission. When a bug is
unambiguous (build broken, fixture crashes, observable wrong
output, structured diagnostic from the bench / debugger), the
fix is autonomous orchestrator work. The user's role is to
direct *features*, not to gate *fixes*.

A bug fix without a regression test is a code change, not a
fix. The test is what makes the fix durable across future
edits.

## Iter cycle

Work is organised into **iters** — tightly scoped commits that
ship a feature, a refactor, or a tidy. Iters cluster into named
families (18a–f, 19a–c, …) where each family advances one larger
concern (e.g. 18a–f together delivers the RC + uniqueness memory
model).

### Tidy-iter at family boundaries

After every named iter family closes, the next iter is a
**tidy-iter**: run `ailang-architect` over the whole surface, read
its drift report, and resolve every item by either (a) fixing the
drift, (b) updating DESIGN.md to ratify what shipped, or (c)
recording in JOURNAL.md that the drift is acceptable and why.

The tidy-iter is non-optional. Without a scheduled cleanup,
codebases grow by accretion — every iter adds, none tears out,
and the deferral compounds across families. Skipping a tidy-iter
requires an explicit JOURNAL entry naming the reason (e.g. a
sibling family is blocking, or the user has asked to defer).

### Performance regressions

`bench/check.py` is the second non-optional element of the
tidy-iter, alongside the architect drift report. Run it at every
family close. The exit code is the gate:

- **Exit 0 (green).** All metrics within their per-metric
  tolerance vs. `bench/baseline.json`. Tidy-iter can close.
- **Exit 1 (red).** At least one metric regressed beyond
  tolerance. Treat the regression like an architect-drift item:
  fix (revert the offending iter, refactor the hot path, diagnose
  with `ailang-bencher` or `ailang-debugger`), or ratify
  (`bench/check.py --update-baseline` together with a JOURNAL
  entry naming the iter that intentionally moved the metric and
  why).
- **Exit 2 (parser misalignment).** The bench-output format
  changed under check.py's parsers. Update parsers or baseline
  schema before re-running. Never claim a regression on exit-2.

Skipping the bench-check at a family boundary requires the same
explicit JOURNAL entry as skipping the architect drift review:
name the reason, name the sibling family that's blocking, name
when it'll be re-run.

A bug-fix iter that adds a new bench fixture (e.g. proving the
fix's invariant under load) bumps `bench/baseline.json` as part
of the same commit. The new fixture's numbers are baseline-zero
on first capture; they become regression-relevant from the next
tidy-iter onward.

Two non-goals to keep clear: (1) per-metric tolerances are tuned
for run-to-run noise on a quiet developer machine, NOT the
language's correctness bar — Decision-10 thresholds (rc/bump ≤
1.3× / p99/median ≤ 5×) live in DESIGN.md and are evaluated
against absolute numbers, separate from the regression check.
(2) Improvements (metric beat its baseline by more than tolerance)
do NOT auto-update the baseline; they are surfaced in the report
so the orchestrator can ratify them via `--update-baseline` with
a paired JOURNAL entry.

### Roles of JOURNAL.md and DESIGN.md

- **DESIGN.md** is the canonical specification. It describes what
  AILang *is*: schema, semantics, invariants, runtime contracts.
  Every new feature must justify itself against DESIGN.md before
  it can ship; if the feature requires changes to DESIGN.md,
  those changes are part of the same iter. DESIGN.md is also the
  artefact `ailang-architect` checks the code against during
  drift review.

- **JOURNAL.md** is the decisions log. It records *why* the
  project moved the way it did — alternatives considered and
  rejected, lessons from past iters, queued options for future
  work, and the rationale behind choices that does not belong in
  DESIGN.md (rationale is about the choice, not about the
  language).

Together they answer two questions: "what is the language right
now?" (DESIGN) and "how did we get here, and what's next?"
(JOURNAL).