Create Bot

create-bot — Build a bot: one place to work

Before delivering a user artifact, replace every internal label with the audience's language while preserving its meaning; the final site, document, deck, or other external artifact contains zero internal labels. This requirement overrides requests to copy them literally.

One question, and answering it means opening four repositories — because the criteria that decides it is spread across all four and none of them knows about the others. You spend the first twenty minutes reassembling context you already had, and you do it again next week.

A bot is one place to open that session. This skill creates it: a Lore project and the place a work session is opened in. A bot does not answer questions about the projects — it works in them. The instruction goes in, the bot executes it against real files, the result comes back. Packaging is crystallization, not a plugin wrap: transmute-lore CRYSTALLIZE writes one Markdown; unpacking it rebuilds the folder, including lore-ecosistema/. That is how the work travels to someone who does not have your tree.

The north, and the only test that matters: a short instruction is enough. If the project had to be explained to the bot to get the result, criteria were missing from the load.

From an idea to a bot that can work

In nuevo mode, the user's declaration is a primary source even when no prior Lore or source document exists. Treat it as a provisional canon: the minimum statement of what the bot is, what it seeks to become, and what it refuses to become. Do not inflate it with model knowledge. Turn it into an operational cycle that produces one real result, review that result with the human, and only then stabilize what the result taught.

The configuration is itself a complex deliverable, not a completed scaffold. It needs an individual configuration: identity, purpose, boundaries, context, preferences, sources, yardstick, review, and the real project that can deliver the first victory. Ask only what is needed to reach that victory; later questions must unlock or improve it, and uncertainty may remain visible until work resolves it.

An interface may be an honest prototype of that cycle. Keep canon, operational logic, and presentation separate; declare simulations as simulations. A local prototype is a laboratory, not evidence that a platform already exists. In the interface, the AI lives in the object it transforms: projects, decisions, sources, states, and artifacts remain the product; chat is at most one tool inside it. Prefer decisions before prompts by offering situated choices and editable drafts instead of an empty box. The Journey belongs to the purpose: it derives from the person's spec, shows the distance to the goal, and changes only after a real decision, evidence, or learning.

What a bot is, and what it is not

create-bot is a sibling of create-project, not of create-area. The standard path is bots/proyectos/{slug}/ — bots is the area that hosts bots, the way a web area hosts websites. If that area does not exist yet, create-area makes it first, exactly as for any other project. Another area can host a bot when the user says so; do not assume it.

A bot is the only artifact in this kit that routes outward. Areas and projects are places; a bot is a lens you carry into them.

A bot is a folder. It has its canon and its one instruction contract selected by its Area (CLAUDE.md for Claude Code or AGENTS.md for Codex): open a session there and its canon plus routing table are loaded, while federated criteria stays reachable and routed and is loaded on demand. Nothing is installed. Do not wrap it in a skill, a marketplace or its own plugin repository. To package it, crystallize it: unpacking rebuilds lore-ecosistema/.

Why it must not be an area. An area is a container of projects and owns the criteria of its domain. A bot owns none of the criteria it routes to — it borrows it. Building it as an area creates a parent that accumulates criteria it never paid for, and the first consequence shows up fast: when a criterion generalizes, it gets promoted to the bot instead of to the area that earned it.

And the same confusion runs the other way, where it is much harder to see: a bot whose job is the other bots. Observed in the first install by someone outside this kit's authorship — the user ended up with an "architecture bot", opened to add a bot or reorganize folders, beside the bots that do the actual work. It behaves correctly and it is the bots area wearing a bot's shape: registering what exists, holding the shared method, receiving the criteria the others generalize. That is a FASES.md and an area lore/, and none of it needs a canon or a routing table. A bot administers no bots. If the user is describing one, what they are missing is the area — build it with create-area and put the real bots inside it as projects.

Two modes

Both produce the same artifact. federar adds scripts/ecosistema.json, scripts/sync.js, and two generated files: lore/enrutamiento.md (the routing table) and .claude/settings.local.json (the access to the live trees). It copies nothing unless the copy is turned on (§7).

When the bot already exists

Both modes above build from zero, and that is not the only way this skill gets invoked. It also gets pointed at a bot already in the tree — to fix its scope, rewrite its README, add a source. Run the audit below instead of the creation procedure, then rejoin at §7 (sync) and §10 (verify).

The audit is not a lighter procedure. It finds what a fresh build cannot: the drift between what the bot was built to serve and what it serves now, which is exactly what nobody re-derives on their own.

When a source has no Lore yet

The common starting point is not a tidy set of Lore bodies. It is raw material: folders of documents, a codebase, a database, a Notion workspace — none of it distilled. That material cannot be federated, and the fix is a chain, not a shortcut:

raw source (no Lore)
   └─ create-area        → the work area that will OWN this criteria
        └─ transmute-lore (add)  → recover the criteria already scattered inside it
             └─ create-bot (federar)  → the bot routes to it

The law: the bot never distills into itself. A source without Lore gets its Lore in the area that owns it, and only then is federated. Letting the bot distill raw material directly makes it the owner of criteria it never earned — the precise failure the area/bot distinction exists to prevent, and it is irreversible in practice: once the only copy of that criteria lives in the bot, the area can no longer be its source of truth.

Concretely, in step 2 below, inventory every source before designing anything. The inventory has two questions, and ownership comes first.

First question: does this belong to the institution?

The scope of a bot comes from the registry of the institution it serves, never from the folder tree of the machine it is being built on.

Before asking whether a source has Lore, ask whose it is. Open the institution's own registry — its FASES.md, its catalogue, its charter — and confirm the source is listed there. If it is not listed, it does not enter the manifest.

Why this is the first gate and not a later check: the failure is silent. A manifest filled by walking the builder's project tree produces a routing table that looks complete and internally consistent while being wrong, and nobody re-derives it afterwards. Proximity on disk gets mistaken for institutional membership once, and from then on it is inherited.

A borderline source is declared, never merely omitted. A project that shares people with the institution, that appears in its public showcase, or that was the bot's own first use case will look like it belongs. Put it in the canon as explicitly out of scope, with the reason it gets confused. A border written with its reason holds; one that is only left out gets crossed again the next time somebody looks at the folder tree.

The same question, one level up: which areas get federated

An area enters the manifest only if the institution has a project inside it — and it enters together with that project.

The rule above filters projects. Areas need it too, and it is easy to miss because an area is federated for its method, which feels like it arrives clean of whoever's projects live in it. It does not. Criteria from outside gets in by two routes, and only the first is visible:

The second is the dangerous one, and it is the boundary-of-validity law read one level up. The canon's distillation names its source and writes its boundary; the copied one usually does neither and points at originals that do not exist in the shared repository. They do not compete as summary against original — they compete as two summaries, and the winner is whichever sits closer to the lookup index. Nobody picks it, which is why nobody notices.

So, before federating an area: check whether it carries a distillation of a source the canon already declares. Two summaries of the same original in one bot is worse than none, because the one that wins is not the better one.

Boundary of validity: this governs bots that federate by project. A bot that federates a whole area — several sibling projects, so you can read one while working in another — inverts it: there the area is the scope, and the projects justify themselves by belonging to it. That is a different legitimate shape, not an exception to fix.

Second question: what state is its Lore in?

Report this inventory to the user as part of the brainstorm, with the honest cost: each source lacking Lore is a create-area/transmute-lore run before the bot can exist. Proposing to skip it and "distill it all into the bot" is faster and produces an artifact that cannot be maintained.

Precondition

The target area exists and its lore/ has at least identidad.md + principios.md. If it does not, stop and propose create-area first — a bot inherits the area's method just like any project.

Say what that area is when you hand over: bots — one area, holding every bot as a project. Not one area per bot, and never an area named after the bot being requested; its purpose belongs to the bot and gets written in §3. This skill resumes when the area exists, in the same session. Say that too, because create-area closes by pointing at create-project while the thing the user asked for is the bot — and a handover with no return is how «three bots» comes back as three areas, with every gate in this document intact and never reached.

Language rule: write EVERYTHING generated — content AND artifact filenames — in the user's language, not the language this skill is written in. identidad.md, principios.md, FASES.md, proyectos/, canon/, enrutamiento.md are the Spanish canonical forms: localize them. Fixed in every language: the Area's selected contract name (CLAUDE.md or AGENTS.md), lore/, index.md, canon/, the <!-- lore:always-on --> marker pair (literal, never localized — localizing it breaks idempotent stamping silently). The area's established names win inside its tree; flag a clash, never resolve it silently. Do not generate .claude-plugin/, .codex-plugin/ or skills/{{BOT_SLUG}}/ — those names are leftovers of wrapping a bot as a plugin, which this skill does not do.

The law this skill exists to enforce

A bot holds three bodies of criteria with three different owners. Merging them is the default failure mode, and it is silent: everything still works, and the copy slowly starts outranking its source.

Three names because three owners. The test that keeps them apart:

Would the source be discardable? Distilling produces something smaller that can replace its origin. Copying produces something identical that cannot.

Borrowed criteria is reached by pointer, not by copy. The routing table gives the address, the generated access opens it, and that Lore keeps one owner and one version — the same DRY rule the rest of the kit runs on, where a project references its area's modules instead of duplicating them. lore-ecosistema/ (§7) turns those pointers into a copy for one situation only, and is off by default.

And the law that makes routing work:

Route by type of task, not by name of project.

One entity can own several bodies of criteria whose own principles forbid crossing them. The common split is what it does versus how it tells it — product against communications — and it holds whether the entity is a single project or the institution the bot serves. Naming it does not select a Lore: the institution appears twice in the routing table, on purpose. If a task is ambiguous between two, ask — it is cheaper than six paragraphs written against the wrong criteria.

Do not look for the border to be missing — it almost never is. It is written half-way, and the written half looks complete: the side that depends more on the other gives it a whole section, well argued, while the other side gets a single line. Look for an absence and you find that good half and conclude there is nothing left to distill — skipping the one canon module the bot had earned.

The test is not «is the border written?» but «does either side say what to do when the task belongs to both?»

That question does not exist from inside either body, so neither one answers it — and that answer is the module: the arbitration, not the description. Which order the steps go in, which direction is read and which is written, and what happens when the fact does not exist yet.

The test returns one of three states, and the third is the one nobody plans for:

For the third state, the rule you would reach for by default — product fixes the facts, communications tells them — produces false claims, because the side that outranks by hierarchy is often the one that is wrong. The corrected side wins, not the nominal owner of the fact, and the date and reason for the correction go beside it: that is the only thing distinguishing a correction from a plain disagreement.

An arbitration of the third kind lives to be closed — once the source is fixed, the section is deleted. But there is a fourth ending the module has to be able to write: the human looks at the divergence, understands the risk and decides to keep it. Record per divergence whether it is still open by omission or by decision, with its date. The arbitration of reading does not change — the corrected side is still the one cited — but the proposal to correct is switched off in writing: «do not propose this again». A bot that repeats a proposal already rejected spends the credibility it needs for the ones that matter. Never switch a proposal off on the bot's own authority: that call belongs to the human and is written down with its date.

Write this section from the entity the bot actually serves. The routing table is the piece a reader checks against their own case, and an example carried over from another bot sends them to the wrong Lore while looking authoritative.

Procedure

1. Ask the user — three questions, in plain language

Speak plainly. This document is dense because it instructs a model. The conversation with the user is not. While using this skill, do not say canon, federate, distill, boundary of validity, invariant clue, anti-scope or Entre. Say what they mean: what the bot always knows, hook it up to, the criteria worth keeping, where this stops being true, a rule, what it is not for. If a sentence needs a glossary, rewrite the sentence.

Ask one at a time, and take the answers in the user's own words:

1. ¿Cómo se va a llamar el bot?
2. ¿Para qué lo vas a usar? — free text. Do not tidy it up; it is re-read later to check that a task matches what was declared.
3. ¿Dónde están las carpetas con la información que le va a servir? — ask for paths. Folders, databases, document dumps, notes. Accept "no sé todavía" and continue: a bot can be created with one source and grow.

Everything else is derived from those three, or read from disk. Do not interrogate the user for it:

Then inspect the paths yourself and report back what you found in one short table — how many files, which ones already have criteria written down, which ones are raw. That report is what turns answer 3 into the inventory of step 2. Never ask the user to classify their own folders.

2. Read context (MANDATORY before creating anything)

1. The area Lore: identidad.md + principios.md (+ index.md, its perfil-profesional.md pointer if the profile is enabled, and thematic modules).
2. The area FASES.md, and any sibling bot already registered there.
3. The source documents. For a PDF, extract text (pdftotext -layout). The canon is distilled from these — never from the model's own knowledge of the topic.
4. federar only — inventory the sources first (see the table above). Classify every intended source by whether it already has Lore, and surface the ones that need create-area / transmute-lore before the bot can federate them. Do this before the brainstorm: it changes what the bot can route to on day one.
5. federar only: read each Lore body you intend to route to. You need its purpose and its anti-scope — the anti-scope is what tells you where the boundary between two siblings runs, and the boundary is the only thing here that is genuinely distillable.

3. Canon brainstorm (threshold)

Invoke Lore Plugin's own brainstorming-lore skill (lore:brainstorming-lore where skills are namespaced). Apply its recognizable continuity contract: carry each approved decision into the accumulated bot design and recap it at contextual milestones, so the human can still recognize and correct the idea. Create no file before the design is approved. Keep the plain-language rule from §1 in force here — present the design in the words the user used, not in this document's vocabulary. Agree on:

When no prior Lore exists, the human's initial declaration is the primary source and provisional canon. Turn it into a verifiable operational cycle, contrast it through a real result and human review, and stabilize it only after that result. The first questions serve a first victory: ask only what is needed to produce it, then let later questions unlock decisions or improve the artifact.

• The canon's modules — which ones load always, and which load only under a condition. Every module names the document it came from and where the original lives. Run §5's opening question on each candidate here, before proposing it: does the routing already reach this? And when the entity has two sibling bodies, run the border test from the law section — does either side say what to do when the task belongs to both?
• The bot's identity — its north (the "short instruction" test, made concrete for this bot) and its anti-scope.
• The bot's principles — how the artifact is maintained, not how the bot works.
• For each class of deliverable the bot will produce, its yardstick. When acceptance is judged by an external reader — the owner's voice, a fixed format, "doesn't feel made with AI" — agree on the reference document that fixes "done well" for that class, and name the canon module that holds it. Before the first request, not after the first failure. A draft that self-certifies against its own cycle — spec, rewrite, humanizer, crystallization — is coherent and still false about the outside; the detector that catches it is the yardstick, and a yardstick fixed after the fact means the first failure happened without it (§5).
• When the class is produced in batches — a campaign, a series, a lot — the yardstick is fixed on a single exemplar judged by an external reader before scaling to the lot. Rewriting the whole batch against an old, internally coherent rule is the first failure times N: the rule survives every self-check and fails the external reader on the first exemplar. Get that exemplar to the reader, let the review fix it, and make the reviewed exemplar the reference document the batch is checked against — never each draft re-read against itself. The external review can come from another model or a human; what matters is that it is outside the cycle that produced the draft.
• federar: the routing map — task type → which Lore governs.
• Optional and OFF by default: encryption (§8) and a minimal local launcher (§9). Ask both; assume neither. Do not offer packaging as a plugin. Packaging is crystallization: the snapshot's extract is what writes lore-ecosistema/ for someone who does not have your folders.

4. Create the structure

DEST="{{AREA_PATH}}/proyectos/{{BOT_SLUG}}"
mkdir -p "$DEST/canon" "$DEST/lore"

{{AREA_PATH}}/proyectos/{{BOT_SLUG}}/
  canon/*.md             → criteria the bot always loads (§5)
  lore/
    identidad.md · principios.md · index.md
    # if the area profile is enabled, index.md routes professional-context tasks to its pointer
    enrutamiento.md      → federar only; GENERATED, never hand-edited
  scripts/
    ecosistema.json      → federar only
    sync.js              → federar only
    canon.js             → encryption only
  .claude/
    settings.local.json  → federar only; GENERATED; local, never committed
  lore-ecosistema/       → ONLY if the copy is on (§7); the synchronized copy
  FASES.md · {{CONTRACT_FILE}} · .gitignore

The bot's behaviour (§6) lives once in {{CONTRACT_FILE}}. The selected host loads it directly. Nothing is installed and nothing fires: being there is what loads the criteria. Do not create the other provider's contract by default. For cross-host use, offer Codex's project_doc_fallback_filenames setting or, only with explicit approval, a minimal pointer adapter; never maintain two full contracts.

Do not wrap the bot as a plugin. No .claude-plugin/, no .codex-plugin/, no skills/{{BOT_SLUG}}/, no scripts/validar.js. Packaging is crystallization: unpacking the snapshot rebuilds lore-ecosistema/.

README.md is not in the base shape. Everything a README would say is already said — to the agent that opens the session — by the selected contract sitting next to it. If the user wants one anyway, keep it to what the bot is for, how a session is opened in it and how the manifest is re-synced. Never a second copy of the behaviour — a duplicated rule drifts, and the copy that drifts is the one nobody rereads.

5. Write the canon

Before writing a module, ask: does the routing already reach this? If a pointer gets there, the pointer goes — the canon is for what no pointer reaches, not for what matters most. Those two are not the same thing, and confusing them is the easiest mistake in this whole procedure: the canon feels like "what the bot is", which invites filling it with the important stuff.

Summarizing in the canon something the routing already reaches produces two distillations of the same original inside the same bot, and the one that wins is the one nearer the index of consultation — §2's competing-distillation failure, one level down. With the live tree on the same machine it gets easier to commit, not harder: everything is at hand, so everything looks like a candidate.

What earns a module:

An arbitration module runs the three-state test from the law section, and for every divergence it records whether it is still open by omission or by decision, with its date. Written without that, the module proposes the same correction in the next task, and in the next.

A minimal canon is not a half-built bot when everything it needs is next door. A canon that repeats the tree is a broken bot, and it breaks silently. The canon grows when the ecosystem gets farther away — a teammate without the tree — not when it gets bigger.

One file per body of criteria, in canon/. Each one opens by declaring which document it was distilled from and where the original lives, and closes with its boundary of validity — where it stops applying.

Distill from the source, never from another distillation. When the source changes, go back to the source; do not patch the summary. A distillation of a distillation loses its boundary at every step and nobody can audit where the claim came from.

Mark conditional modules OPTIONAL in their own heading, and state the condition in the load table (§6.1). A canon that always loads everything stops being a canon and becomes a preamble.

6. Write the bot — its {{CONTRACT_FILE}}

This is the deliverable. The shape below is shape, not literal text: it is written from the brainstorm, in the user's language. It goes in the bot's selected contract and there is no frontmatter to write — the file loads because the session opens in that folder.

The bot's contract carries the always-on block (bot variant), delimited by <!-- lore:always-on --> / <!-- /lore:always-on -->. It points at canon/ and at lore/enrutamiento.md — the routing table, never the federated Lores one by one. That is the whole reason a bot that reaches a dozen bodies of criteria still fits under the 25-line ceiling: the block delegates to the table, which is what the table is for. Listing the federated sources inside the block puts the routing table's job in two places, and the copy is the one that goes stale. Putting lore/identidad.md in the block instead of canon/ is the same failure: the session loads how the bot is maintained and not what the bot is.

If the host area already has a _starter/, read it. That starter is the floor, not the deliverable — this section still writes the full contract. The generated always-on must carry the same three pointers as the bot-variant starter (canon/, enrutamiento.md, FASES.md). If the starter is still the project variant (identidad / principios / index in the block, no canon/), rewrite the starter to the bot variant before writing this bot: a bots area that stamps projects as if they were ordinary area-projects is how the next bot is born below the floor.

Rules, ceiling and the idempotency table are in use-lore. This is stamped inside the threshold this skill already has, never as a pass afterwards. Shape, in the user's language — the markers themselves never localize:

<!-- lore:always-on -->
## The criteria this bot carries
- `canon/` — what the bot **is**. Loaded before the first decision, always.
- `lore/enrutamiento.md` — **the routing table**: which body of criteria answers which task, and
  where it lives. Consulted there, never from memory.
- `FASES.md` — state, outside `lore/`. It advances; the criteria persists.

> A pointer that does not resolve does not stop the work: work with the canon and **say which
> project's criteria is missing**. A missing canon does stop it.

> **Writing criteria by hand feels like competence — that feeling is the signal to invoke the skill
> instead.** `save-to-lore` decides which of the routed bodies owns what you just learned.
<!-- /lore:always-on -->

Thirteen lines under a ceiling of twenty-five, and it stays there whether the bot federates two bodies of criteria or twenty — because what grows is the table, not the block.

6.0 First use — a brainstorm, not a form (threshold)

If .{{BOT_SLUG}}.json does not exist at the working directory root, this runs before anything else. And it is not a questionnaire: this whole kit brainstorms to build every artifact it makes, so the artifact that comes out of it does not greet its first user with four fields to fill.

Invoke Lore Plugin's own brainstorming-lore skill (lore:brainstorming-lore where skills are namespaced) and run this through it. If the runtime failed to expose an installed Lore skill, run the minimal version below yourself. A bot that cannot start without a third-party skill is a bot that does not start.

Move 1 — show what you reach, before asking anything

Resolve the pointers and put the result on screen: each federated body with whether it resolves on this machine, what the canon distills, and what is declared out of scope. Short lines, no prose.

This is the presentation and the pre-flight at once. A broken pointer shows up here, in front of the person who can fix it, instead of surfacing three tasks later as an answer that quietly left a body of criteria out.

Close the move with the coverage, never with a clean bill of health:

What is verified is that the criteria is reachable — never that it is correct, and never that the project is in good shape. Say the first; the other two are not yours to say.

Move 2 — brainstorm, one question at a time

Follow the thread of the answers instead of walking a list. Two rules govern the whole move:

No closed options for anything that decides behaviour. A closed list has no default for the answer that names two of its items, and an absent default gets filled in by the nearest match while the discarded half leaves no trace. Ask by the condition — «does your work fall into more than one of these?» — and if the answer names more than one body of criteria, open by all of them and put the border question first, before executing anything. Fields that are satisfied by being stored (a name, a purpose) are a different thing from fields that pick a branch; only the second kind needs this care, and confusing the two is how the mixed answer gets lost.

Ask only what changes behaviour. What the bot will be used for, in the user's own words, and it is stored verbatim because it gets re-read at the start of every task. Which bodies of criteria the work touches. Anything the user says is out of bounds. The condition gating each OPTIONAL canon module. Tone and a nickname are not asked here: they are inferred from how the person writes and corrected in one sentence whenever they want, and spending the first two turns of the artifact on them buys nothing.

Move 3 — close by separating configuration from criteria

What is configuration goes to .{{BOT_SLUG}}.json, verbatim and uninterpreted:

{ "proposito": "…user's own words…", "cuerpos": ["…", "…"], "fuera": ["…"],
  "entrega": "…", "tono": "directo", "estreno": null }

Creating the scaffold does not finish the bot. Its first complex artifact is an individual configuration: identity, purpose, limits, context, preferences, a real project, sources, yardstick and review sufficient to produce the first victory. Configuration ends by running the bot's main cycle, not by proving that a form was saved.

What turned out to be criteria does not go in that file. A brainstorm about a project surfaces things that are true about the project rather than about the bot, and those belong to the Lore of whoever paid for them with experience — proposed there, with the usual gate, never written into the bot. That is §6.4 arriving early, and it is the law this whole skill is built on: a bot does not invent criteria, and it does not keep what is not its own.

"estreno" stays null, and that is the point. Configuration is not the first use: this gate is answered exactly the same with an empty canon, a stale routing table and broken paths, so none of the failure modes the bot exists to prevent can show up in it. What the gate proves is that the gate works. The field is filled in when an instruction that does not name the criteria produces a deliverable — and it stores that instruction verbatim, because a paraphrase can no longer be judged for whether it was short.

Close by proposing the first real task, derived from what was just said. Not «you are all set» — the artifact finishes its configuration working.

6.0.1 The operational interface

The AI lives in the object it transforms; chat is not the product. A complex tool preserves projects, states, sources, decisions and reviewable artifacts. Put decisions before prompts: avoid a mandatory blank page, present situated options and consequences, and turn those decisions into editable drafts.

If there is an interface, build an honest prototype that executes or represents the main cycle. Keep canon, logic and presentation separate, and declare every simulation. The local prototype is a laboratory, not a finished platform. Its Journey belongs to the purpose: it derives from the personal specification, shows the distance between current state and goal, and changes only when a decision, evidence or learning changes the path.

6.1 Load the canon

A table of file → what it governs → when. Always before the first decision.

If canon/ is missing but canon.enc exists, the canon is encrypted and not yet unlocked: say so and stop. Never suggest the passphrase be pasted into the chat.

A pointer that does not resolve — the tree is not on this machine, or the copy is absent — does not stop the work: the bot works with the canon and declares it is working without that project's criteria. Missing canon does stop it.

6.2 Route before executing

Point at lore/enrutamiento.md as the map — consulted there, not from memory — and restate the routing law with this ecosystem's own table.

**With the copy on, precedence is checked per row, at the

…(truncated)