Archetype Packs

An Archetype Pack is scaffolded content — Blueprints, Flows, Specialists, Loops — for one of the five roles a codebase moves through over its life.

Packs are the implementation. team is the only verb you see:

alc team hire builder      # write the pack's missing files, then lint
alc team list              # what is hired, and the state of any loops it brought
alc team status            # …plus Mix Health
alc team retire builder    # archive that member's loop definitions
alc team remove builder    # delete the pack's unmodified files (customised ones stay)

Hiring is additive: it writes only the pack's missing files and refuses to overwrite one you already have. --force overwrites all of them, replacing local edits. A Specialist's Knowledge File is not a pack file and is never touched by hiring.

Retiring is not un-hiring: it archives the member's loop definitions into loops/retired/ and the member stays on the roster — a member counts as hired while any of its pack files is on disk. remove is the exit: it deletes only files still byte-identical to what the pack would write today, keeps (and lists) anything you customised, and is reversible — hire rewrites exactly what it removed.

A bare alc team is the same as alc team status, so the command family opens on observation rather than a usage error.

The five#

The Grower pack is the thinnest of the five. It ships a listen Specialist you drive yourself: you point it at your issues and errors, and it sweeps them. What it does not ship is automatic intake of those signals, or a loop kind that replenishes itself from regressions. Both of those exist in the control plane and work with any Blueprint — they are simply not wired up for you here. Hire it for the Specialist; do not expect it to run unattended out of the box.

The Sweeper's unship gate#

Worth singling out, because it shows what "checks are law" means in a case where the obvious approach is wrong.

Removing a feature is only done when the codebase still holds together without it. So the unship Flow ends in a pure verification gate: a remove stage does the deletion, and a gate stage (verify_only: true) re-runs the project's real check set. A removal is judged by the same build, test and lint that guard every other change — not by a bespoke rule the Sweeper invents.

Three deliberate choices around it:

• expect: shrink is advisory. The refactor Blueprint declares it to state that this mandate should reduce the codebase. When a shrink run finishes net-positive, the control plane records a warning. It never fails the run — simplifying sometimes means growing before shrinking.
• Proving absence by text search is opt-in, and off by default. An earlier design grepped for each removed symbol. Text search is only a heuristic: a name that is not unique can never be proven absent. The scaffolded unship.yaml carries that recipe as a commented block you can uncomment, and the map Blueprint still ships for it.
• A project with only placeholder checks is reported inconclusive. When the only resolvable check is the ["true"] smoke placeholder, require_real_checks reports the removal as honestly unverified rather than fabricating a green pass. The fix is to give the project a real check_set.

To adopt the real-checks gate in a project that predates it, re-scaffold with alc team hire sweeper --force.

Stage and Mix Health#

stage in the Manifest declares which phase of product life the codebase is in:

stage: growth     # pre-pmf | growth | strong-pmf

Each stage has a target archetype mix. Pre-PMF centres on prototyper, builder and sweeper; growth on builder, sweeper and grower with some maintainer; strong-PMF on sweeper, grower and maintainer with some builder.

That is a health heuristic, not a law of physics. Override it wholesale:

stage_mix:
  core: [builder, maintainer]
  secondary: [sweeper]

Every rule the stage drives is advisory. A core archetype with no Blueprint hiring it produces a warning and an alc team hire <archetype> hint. A compute_tier: deep Blueprint whose archetype sits outside the mix warns too. A Blueprint with no archetype is never penalised. The stage never changes how a mandate executes — its authority stops at warnings, reports and scaffolds.

Mix Health (alc team status) answers the question the mix exists to ask: is the autonomous work actually the right work for this product's stage? It aggregates every archived run report by archetype — runs, span, cost, net lines — and sets the real spend against the target mix. With no stage declared it still shows the breakdown; it just never judges it.

alc init --stage growth      # sugar over `alc team hire` for that stage's combo

The Conductor is stage-aware, in two parts#

Deliberately with different guarantees:

• A prose briefing nudges the planning model toward the mix. Probabilistic — the model may ignore it.
• A deterministic check runs after the plan comes back and warns when the planned units drift from the mix. That second part is the actual guarantee.

alc conduct --strict-stage turns that warning into a refusal. With no stage declared, neither part changes anything.

archetype: is a label, not a switch#

archetype: on a Blueprint's front-matter is a descriptive label with zero runtime effect. It is copied to the run report and it is what Mix Health aggregates by. Behaviour always lives in a named field — check_set, needs_service, mode — never behind this string.

That is a design rule, not an accident. A label that quietly changed execution would be an invisible second policy language.

Next#

• The Scorecard — the per-run metrics Mix Health aggregates.
• Autonomous Loops — the loops these packs bring with them.