Save To Lore

---
name: save-to-lore
description: Use when saving a lesson to the Lore, right after solving a problem worth keeping, when distilling Lore from an external body of criteria (a skill, a style guide, a third-party playbook), or when reviewing a folder of loose notes to decide what becomes criteria or state. Trigger on "save to lore", "distill this to the lore", "guarda en lore", "distill this skill", "destila esta skill", "guárdalo como formato base", "esto es el estándar de ahora en más", "revisa mis notas", "mina la bandeja", or proactively after resolving a friction that passes the Lore bar (constraint + signal + executability + genericity).
---

# save-to-lore — Incremental capture and promotion

The bug is fixed. The tests pass. You are already reaching for the next thing — and the most
expensive part of the last two hours is not the patch, it is the sentence you would say if someone
asked *why it had to be done that way*. That sentence has about a minute left before it is gone.

This skill catches it. It captures a friction into the **current project's** `lore/`, then promotes
to the project's **mother area** the clues that are already **confirmed + generic**. It is the
incremental counterpart to the structural skills: `transmute-lore` migrates a whole project;
`save-to-lore` adds one clue at a time and routes it to the right level.

> **This pass is bracketed by MYCELIUM, and both ends are mandatory.** Set up two todos before you
> write anything. **Entry:** if this pass will lean on existing Lore to decide where things go, open
> with a MYCELIUM entry scan (`transmute-lore` MYCELIUM) and address its findings first. **Exit:**
> after you write, close with a MYCELIUM exit scan over what this pass produced — detail in *Closing
> either mode*, below. **The pass is not complete** — do not report success, do not hand back control
> — until the exit scan has run and every finding is written as a junction or explicitly declined
> with a reason. Deferring a junction "to a later pass" is not a completion state; it is the exact
> failure the exit scan exists to catch.

> **Language rule:** write every clue, index line and law in the **language the target lore already
> uses** (consistency wins); if the lore has no established language yet, use the **user's
> language** — never English by default. The same applies to filenames: new module files are named
> in the target lore's language, and existing files are never renamed by this skill (that is
> `transmute-lore` TRANSLATE's job). Artifact names in this skill (`identidad.md`, `principios.md`,
> `proyecto.md`…) are Spanish canonical forms — use the corpus's actual localized names. Relative
> paths, confidence markers (`conjecture`/`confirmed`), the ` · ↑` glyph, the `<!-- lore:always-on -->`
> marker pair and general technical English terms stay as-is.

> **The area is the shared corpus.** A project lives in `{area}/proyectos/{name}/` and inherits from
> `{area}/lore/`. Generic, confirmed criteria belongs in the **area** (every project sees it);
> project-specific criteria stays in the **project**. This skill decides which is which.

## Loose-note function — load only for note tasks

When the request points at `notas/`, `notes/`, `apuntes/`, meeting notes, or any folder of `.md`,
`.txt` or `.docx` and asks to review, integrate, extract, distill or save its contents, **read
[`notas.md`](notas.md) before touching the files**. That file owns the source-side sweep,
frontmatter, four-bucket classification, debt report and archive. It is app-neutral: Obsidian is one
possible editor, never a prerequisite.

Do not load `notas.md` for an ordinary CAPTURE or GRAFT whose source is not a loose-note folder.
The separation is deliberate: users who never keep notes should not pay for the mining procedure.

## Before anything: the mode is decided here, not before you arrived

If you already drafted the entry and are invoking this skill to check it, **stop and classify the
source first.** The mode is not formatting applied to a finished draft — it changes what the entry
must contain. A draft written assuming CAPTURE, when the criteria was actually imported, is missing
its provenance header, its confidence split and its defeats section. And a module with no defeats
does not enter at all.

The tell that you skipped this step: the draft reads like a good summary of the source. That is the
failure state of GRAFT, not its output.

> **Routing gate — before you write:** If your task touches an artifact that is **not a clue** — the `<!-- lore:always-on -->` block, the host contract, `FASES.md`, `enrutamiento.md`, or the shape of the tree — **stop: this is `transmute-lore` (LEAVE/CLEAN/PRUNE class), not CAPTURE/GRAFT.** Writing the clue in its module **and** its line in `index.md` is one capture, not two artifacts; promotion to the area (`index.md` does not count as the second artifact) is still CAPTURE. Check `use-lore` routing table first; if no row matches, run `brainstorming-lore` before choosing a skill. Batching 5 edits without that check is how `Exit` landed in the wrong file (`H14` for skills, `837eb73` fix).

## Two modes — pick by the SOURCE of the criteria

| Mode | Source | What it is |
|---|---|---|
| **CAPTURE** (default) | **lived friction** — a bug, a collapse, a client rejection | The scar. Everything below (threshold, routing, promotion) is written for this mode. |
| **GRAFT** | **imported criteria** — a skill, a style guide, a third-party playbook, **another kit's constitution or governing document** | Criteria already distilled **by someone else, under someone else's purpose**, arriving with no validity boundary declared. |

> **Why it is called grafting, and the metaphor is load-bearing.** A graft is foreign tissue bound
> to a rootstock that is already alive: it takes root or it is rejected, and what grows afterwards
> belongs to the host. A graft nobody watches is deadwood tied to a healthy tree: you say what took
> root and what did not. This mode is the exact counterpart of `transmute-lore` PRUNE — **pruning
> removes what the plant grew on its own; grafting judges what came from outside.** Those are the
> two passes of a maintained Lore, and having one without the other is why a body of criteria either
> bloats or ossifies.

> **The law of GRAFT: an external body of criteria is not distilled — it is arbitrated.** Only
> what survives the collision with **this** Entre's purpose enters the Lore, and the record must
> state **where the source loses**. A faithful summary of a skill is not Lore: it is redundant
> literature wearing the authority of an Invariant Clue. What the source *loses* is worth more than
> what the source *offers* — the summary already exists (better written) in the source; the
> disagreement exists nowhere else.

> **When GRAFT runs on a schedule, it starts by reading what already lost.** A one-off import
> reads the source cold; a recurring pass over a field that moves slower than the schedule will keep
> meeting the same material. The defeats sections this mode already writes **are** that ledger: read
> them first, and do not re-arbitrate or re-report what is already in them. **"Nothing entered this
> time" is a valid result and is written as such** — a recurring pass that always finds something
> stopped looking and started justifying itself.

> **A third-party skill you *invoke* carries criteria too, and it applies it without asking.**
> GRAFT is for criteria that arrives as a **document** to be read. The harder case is criteria
> that arrives as a **tool that runs**: a formatter, a linter, a style checker, a writing reviewer.
> Nobody arbitrates those, because they look like capacity. They are not: every opinionated tool
> ships a body of criteria, and yours loses silently every time the tool runs.
>
> **Feed it your Lore, in the invocation, as its input.** Most such tools have a calibration clause
> that makes a provided sample outrank their defaults; the ones that do not should be treated as
> capacity and kept away from anything the Lore governs. Observed case: a writing-cleanup skill
> flags emoji and short-fragment bursts as machine tells. A brand whose distilled voice is built on
> exactly those two devices ran it cold and would have had its voice erased by a tool that was right
> about everything except this corpus. **A tool is not neutral because it is useful.** Second observed
> case (2026-08-24): a general design skill invoked to shape a UI decision optimized on its own axis —
> container complexity matching content effort — against a standard whose actual north was
> memorability and a strong point of view; the two disagreed and the design skill's axis lost. The
> difference from the first case: this one was arbitrated **before** the artifact shipped, because a
> person asked for it explicitly, not because any step required it — the junction this pattern still
> needs (`H14`, on the kit itself) stays open.

### GRAFT — hygiene before the gates (GLOSSOPETRAE, 2026-08-21)

Imported text can carry invisible payload that survives human review for one tokenizer family and executes for another (`R=100% M=0%` tag-char/PUA, Anthropic 10 blind spots `PAPER.md:2.5`). Before the four gates, **sanitize deterministically**: strip `Cf` tags U+E0000-E007F, PUA U+E000-F8FF, ZWJ/ZWNJ/ZWSP/BOM and variation selectors. Treat `empty/unparseable ≠ clean` — alarm on empty as distinct class, never collapse to "said no". For confidential sharing of a crystallization, wrap with `zip -P` / `age -p` outside the Lore; do not glyph. No semantic detector is deployed.

### GRAFT — the four gates

1. **Capacity or criteria?** A source that brings **capacity** (it *executes* something: renders,
   crawls, compiles) is **not Lore** — record it as a dependency (how and when to invoke it) and
   stop. Only a source that brings **criteria** (it *judges*: what is good copy, good design, good
   SEO) is arbitrated. Confusing the two produces either a bloated Lore or a tool reimplemented by
   hand.
2. **Does this Entre have a written purpose?** Arbitration needs a yardstick. If `identidad.md` (the
   standard) is empty or missing, the only available move against an authoritative source is to
   **obey it** — so **stop and say so**: write the identity first, import second.
3. **Collide, don't copy — form and posture.** Go through the source against the standard on **two axes: form and posture**. Keep only what constrains a future decision **here**. Where source and standard conflict, **the standard wins** and the conflict is resolved into a new clue (that resolution is usually the most valuable line produced: it exists in neither body). Posture = stance the professional takes toward the reader (e.g. Pollo Pepe: defect of character, never of competence).
4. **Exit threshold — the defeats section.** The resulting module MUST carry an explicit section
   naming where the source contradicts our standard and loses. **No defeats = no entry:** either
   nothing was arbitrated (it was a copy), or the source carried capacity, not criteria.

> **A governing document is the hardest case of GRAFT, and the one most often skipped.** When a
> second kit ships a constitution, a charter or a set of rules that declares its own authority, the
> reflex is to treat it as configuration and adopt it. It is not configuration: it is criteria
> written under someone else's purpose, and a clause claiming supremacy is precisely the kind that
> **loses** — a kit installed this week cannot govern criteria paid for with friction before it
> existed. That defeat is written down, not merely omitted: an omission leaves a hole, and the next
> template regeneration fills it back in.
>
> The one thing that does **not** happen is deferring to it while deciding. Arbitration is judgment,
> not negotiation.

**Confidence in GRAFT:** what is adopted *from* the source enters as **`conjecture`** (nobody has
paid for it with real friction yet). The **arbitration itself** — the defeats, derived from an
already-validated identity — enters as **`confirmed`**. Head the module with its provenance:
*"Distilled from `<source>`, arbitrated against `<identidad.md>`."*

### GRAFT — reconstructed criterion (source is work, not document) — 2.3.0

If the source is not a document with an author but **work that was never written** — the criterion of a professional reconstructed from observing their output — the reconstruction **can be a projection**. The entry MUST carry the **evidence that forces the reading** and the **size of the corpus looked at**. Reference case: `estandar-del-rubro.md:§3.3`, 12 publications of 739. If either slot is empty, the entry does not enter.

### Closing either mode: what you just wrote is not plugged in yet — 2.3.0

**A new clue is born `Aislada`.** Writing it in the right module, with its boundary declared, does
not connect it to anything: nothing yet obliges any step to run it, and that defect produces
**inertia, not error** — the next deliverable comes back looking fine and violating it.

So a pass that lands criteria closes by naming, for each entry, **the step that will run it and
where that step leaves an artifact**. If you cannot name one, say so in the same breath as the entry
— an unplugged clue is a real result, not a failed save, and hiding it is what makes it undetectable
later.

**Done means the exit scan ran.** When the pass wrote more than one clue, or touched a procedure,
running `transmute-lore` in `MYCELIUM` mode over what it left (trigger 3, *on the way out*) is not
the last optional courtesy — it is the line between *written* and *done*. The scan that ran *before*
the pass is structurally blind to what the pass produced, and `GRAFT` in particular imports criteria
that arrives with no junction by construction. So: do not report the save as finished, and do not
move to the work that was going to lean on this Lore, until the exit scan has run and every finding
it returns is either written as a junction on both sides or declined in writing with its reason. A
finding parked as "connect it in a later transmute-lore pass" leaves the pass **not done**, and the
next deliverable runs against a clue nothing invokes.

## Before either mode — is this a fact, or is it criteria?

The routing below is built for **criteria**, which lives in exactly one place by design. A
**verifiable fact** — an address, a figure, a date, who does what — behaves the opposite way: it is
repeated in every artifact that ever cited it, and in the source document that handed it out. Fixing
it where the error was noticed does not fix it.

> **The unit of work for a fact is the set of its appearances, never the file where it was noticed.**

> **Before distilling a fact from what is at hand, ask whether an authoritative source exists — if it
> does, take the fact from there.** Sampling outputs (published pieces, rendered images) while the
> source exists produces a corpus that is internally consistent and externally wrong, and a provenance
> note on the sampled values *raises* confidence in the bad datum. The question costs one message; the
> wrong fact costs one correction per appearance, forever.

A correction is made where the error turns up, and that place feels like *the* place. But the fact
did not come in from there — it came **down** from a source corpus that distributed it to every Lore
that cited it. Correcting downward from one leaf leaves the root intact and every other leaf with it,
and the root hands the fact out again the next time anybody distills. None of the survivors produce
an error: they get quoted as if they were true.

When what you are saving is a fact rather than a clue:

1. **Search the whole tree for the fact before writing the correction** — `grep` the figure, the
   name, the address. Count the appearances.
2. **Fix all of them in one pass**, and report the count. One fixed out of five is not a fix.
3. **If it also appears in a source document that is not edited**, mark it there too — struck
   through and dated, not deleted. A source that silently contradicts the Lore is the mechanism that
   re-injects the error.

*Boundary:* this covers **repeated, verifiable facts**. It does not authorize duplicating a clue —
criteria lives in one place on purpose — and it does not say a source corpus may be rewritten freely:
it says that if it is corrected, the correction is **visible**. Marking the source is a decision, not
a validated pattern: in another project the source may need to stay untouched with the note kept
somewhere else.

## Three triggers

1. **Explicit:** the user says "save to lore…", "distill this to the lore", "guarda en lore" — or
   points at a source: "distill this skill", "destila esta skill" (→ GRAFT).
2. **Proactive:** you just solved a friction and propose saving it — **only** if it clears the
   **threshold** (below). Cosmetic changes (color, aesthetic reshuffle) do NOT count.
3. **Approved artifact, not a friction** — the user says "guárdalo como formato base", "esto es el
   estándar de ahora en más", or names an artifact as the new floor. Source is **agreement, not
   failure**: the artifact just cleared a bar the person holds, and that bar is criteria with the
   same legitimacy as a scar — it is lost the moment nobody rewrites it as a clue by hand.

> **Trigger 3 stays explicit on purpose, and does not widen into trigger 2's territory.** An
> approval signal ("me encanta", "queda perfecto") is **not**, by itself, trigger 3 — it is evidence
> a proposal is due, exactly like a friction is for trigger 2, and it is offered the same way:
> shown, never auto-written. Turning approval itself into an automatic capture would remove the one
> thing the Lore bar exists to do — **lose** candidates on purpose — precisely where losing is
> hardest, because nobody discards what they just approved. Observed case (2026-08-24): the signal
> fired exactly as predicted and nobody built to catch it — the human remembered on their own. That
> is trigger 3 working as **evidence a proposal was due**, not proof it should have fired itself.
>
> **What to capture is the artifact plus the trace, never the artifact alone.** An approved artifact
> by itself already lost the reasons it took the shape it did — which alternative it beat, and why.
> A pass that absorbs only the final artifact reproduces the same gap that produced it late: the next
> artifact in the same family hits the same missing distinction, because the "me encanta" never
> carried the *why*. So the entry carries three parts, not one: the artifact **named as reference**
> (linked, not re-described — re-describing it is the CAPTURE failure mode again, one layer up),
> **what it is not** (the near-miss it beat, in one line each), and the confidence, capped at
> `conjecture` until a second approved artifact in the same family confirms the same shape.

The proactive trigger is contextual, not constant. Keep candidates during the session and suggest
capture at a **contextual milestone**, or when several **related clues accumulate**. Before writing,
show the **destination, wording, and why it is worth saving now** in plain language. When many
candidates have accumulated, offer to **save them together**. The one human threshold is seeing how
they will enter; after approval, write and make the corresponding commits without asking again for
each clue or commit. Never push.

> **The old name still works.** Somebody saying *«transplant this»*, *«trasplanta esta guía»* or
> *«arbitra esto»* means `GRAFT`: run it, and mention the current name once, in passing. A rename is
> the kit's problem and never the user's — a person who learned the word from a version that shipped
> is owed the operation, not a correction.

### The input can be a note, not only a conversation

A standalone source note may enter either mode directly. A folder or inbox of loose notes uses the
conditional function in [`notas.md`](notas.md) first; it preserves source-side tracking before this
skill writes any destination.

### A professional profile is learned, not collected

When the tree carries `lore/perfil-profesional.md`, treat it as the optional, portable profile behind
the person's memory card. It grows through **small, approved clues** that surfaced while completing
real work — role, verified experience, working purpose or an explicit professional goal — never
through a first-use questionnaire. A CV, profile or credential is source only when the person chose
to share it.

At a contextual milestone, preview one compact addition with its source and destination. Do not
infer sensitive attributes, personality, competence or private history from tone or behavior. Keep
the master fact in the nearest owning area and let projects and bots carry a pointer plus their
situated role; do not duplicate the biography. If the profile was disabled, do not create the file or
make biographical capture proposals indirectly.

## The Lore bar (for the proactive trigger, all 4 must hold)

1. **Constraint** — does it forbid a future error or demand a standard? If it constrains no future
   action, it is redundant literature → do not save.
2. **Signal** — distillable to Context → Cause → Clue, without raw logs?
3. **Executability** — an unambiguous directive you can act on next time?
4. **Genericity** — would it help another project in the area (not a client-only quirk)?

> **What the threshold is holding back is not bad entries — it is the pull that produces them.**
> Having lived something creates an urge to keep it, and that urge peaks right after the friction,
> which is the exact moment this skill runs. An entry that fails the threshold almost never looks
> wrong; it looks like something worth keeping, written by someone who was there. Saying no to it is
> not hygiene applied to a folder. It is accepting a loss on purpose, one entry at a time, so that
> what stays keeps its force.

## Routing — project vs area

**"The domain is the classifier."** A clue is generic if it belongs to a domain the **area owns**
(a thematic module the area carries, e.g. animation, layout, scroll, responsive, routing, testing,
copy — plus any backend domain the area declares). Project-only material lives in files the area
does not own and **never** promotes.

| What you're saving | Destination |
|---|---|
| Technical scar in a generic domain, **confirmed** | area module `{area}/lore/<domain>.md`; project `index.md` points to it (`../../../lore/<domain>.md`) |
| Technical scar in a generic domain, **conjecture** | project `lore/<domain>.md` for now; promote once confirmed |
| Scar tied to project-only code / a client quirk | project `lore/proyecto.md` (create if absent) — never promoted |
| A generic invariant **law** for all projects (confirmed) | propose adding to `{area}/lore/principios.md` (gated) |
| A law specific to this project | project `principios.md` (its own "## Este proyecto" layer) |
| A generic quality-standard refinement (confirmed) | propose adding to `{area}/lore/identidad.md` (gated) |
| Identity/standard specific to this project | project `identidad.md` (its project layer) |

**Default posture:** always **capture in the project first** (local, safe), then **propose**
promotion to the area. Never write the area silently.

## Flow (three steps, one pass)

### Step 1 — Capture (in the CURRENT project's lore/)

1. Distill the input into the triad **Domain → Symptom/Cause → Invariant clue**.
2. Choose the file by domain:
   - Generic domain → project `lore/<domain>.md`.
   - Project-specific → project `lore/proyecto.md` (create if absent). **Not** promotable.
   - A law/standard → the project layer of `principios.md` / `identidad.md` (see routing table).
3. Write the full entry in that file, and one line in the project's `lore/index.md` with the index
   format: `` `domain` · symptom · confidence · [file](file) ``.
   **A paragraph is a paragraph** (kit invariant in `use-lore`): the clue's prose runs to the
   period, not to column 80. Do not hard-wrap mid-sentence.
    - Confidence **`conjecture`** by default; **`confirmed`** only after real validation — the running
      app where there is one, and otherwise the corpus behaving the way the clue predicted.
      **Honest confidence:** never inflate to `confirmed` just to force a promotion.
    - **Falsification is not induction, and one case can settle it.** A clue that *denies* something —
      this measure does not track quality, this check does not discriminate between versions — is
      `confirmed` by a single counter-example, because one is all it takes to break a claim of
      «always». The positive form of the same sentence needs accumulation and stays `conjecture` far
      longer. Do not average the two: asking «how many cases?» without first asking **which shape the
      claim has** leaves a settled finding sitting in `conjecture`, and lets one lucky run pass for
      `confirmed`.
    - **REQUIRED slots when the entry declares a destination:** `destino:` (module + step) and **landing verification** — `grep` the declared term in the declared file and report `arrived / written, never exercised (conjecture)`. **A landing condition is not an ascent condition:** a clause that depends on the criterion being applied is landing, not ascent.

#### The junction is written on both sides — 2.3.0

The clue declares `destino:`; **the step names the clue back.** One line at the destination — *«runs
`<module>` → `<clue>`»* — is what makes the junction verifiable from **either** end.

**Why one direction is not enough, and it is not symmetry for its own sake.** A clue and the step
that runs it frequently live in **different trees**, and a session loads the always-on block of its
own tree and nothing else. With the pointer written only on the clue's side, anyone standing at the
step sees a procedure with no visible obligation behind it — and a later `PRUNE` there removes it as
surplus, because from that side it *is* surplus. The reverse holds too: a scan run from the step's
tree cannot confirm the clue exists without opening a repository it was never told about.

**Observed case, 2026-08-22:** a clue in a research project's `lore/principios.md` and the step that
runs it in a skill living in a different repository. Written on both sides in the same pass, a
`MYCELIUM` from either tree can now classify it without opening the other one.

*Boundary:* applies when the clue declares a destination at all. A clue governing continuously while
writing — a register, a tone — has no step to name it back, and demanding one would invent a junction
that does not exist.

#### Landing check (when destino is declared) — 2.3.0

If the entry declares a destination, run `grep -r "term" <file>` on the declared file **before closing the threshold**. If the term is absent, keep the clue as `conjecture` with note `escrito, nunca ejercido` and report it. Promotion of that clue is blocked until the destination is written. A check that is fulfilled by reading (`IF reading THEN considered done`) is not a point of application — it has no verificable artifact within the threshold.

#### Writing a law into a body that already has laws

A Lore grows by accumulation, so a new law usually leans on a distinction an older one already made.
**It inherits the older law's statement and not its boundary** — the boundary is written last, as a
note about *that* law, while the reasoning the new one needs sits in the body above it. So the
conclusion gets carried over and the condition attached to it does not, and the new law reads as
absolute in precisely the case the first one had declared exceptional. Nothing in the text warns
about it: the result looks complete and consistent and fails only in the rare case, which is the one
the boundary named.

Two habits, and the second is the cheap one that pays every time:

- **When the clue cites another law, open it and look for its boundary of validity.** If it has one,
  the new clue inherits it or says why it does not.
- **State the rule by its condition, never by the category the condition usually holds in.** *«Does
  any of this fall outside the scope?»* survives the rare case; *«only for projects»* does not,
  because the category was a shorthand for the condition and nobody remembers that it was.

*Boundary of validity:* this applies to bodies of criteria whose laws cite each other, which is any
Lore that grows by accumulation. A flat list of independent rules has no inheritance to break.

### Step 2 — Promotion review (always, after capturing)

1. Resolve the mother area: the project at `{area}/proyectos/{name}/` promotes to `{area}/lore/`.
   If the project has **no parent area** (standalone), skip promotion and say so.
2. Read the project's `lore/index.md`. Candidates = lines that meet all three:
   - confidence **`confirmed`**, **and**
   - the domain is one the **area owns** (a module present in `{area}/lore/`, or a declared area
     domain), **and**
   - the line does **not** end with the `↑` glyph (not yet promoted).
3. For each candidate:
   a. Route by domain → target file `{area}/lore/<domain>.md`.
   b. **Dedupe:** grep the symptom text in the target file. If already there → **skip** and report
      it (no duplicates).
   c. If the target file does not exist (first clue of that domain) → create it with the same
      section header the project's lore files use.
   d. Copy the **full clue entry** (Context → Cause → Clue) from the project's `lore/<domain>.md`
      to the end of the target file.
   e. Add the line to `{area}/lore/index.md`, under the matching topic heading (create it if
      missing), linking to `<domain>.md`.
   f. In the project's `lore/index.md`, mark the line as promoted by appending ` · ↑`.
4. Show the user a summary (what was captured, what would be promoted, what was deduped, what is
   pending). If the preview threshold already approved the batch, write and make its corresponding
   commits without a second authorization per clue or commit. Never `git push`.

### Step 3 — Inbox debt (one line, only if an inbox exists)

If the current project, area, or bot has a free-note inbox, follow [`notas.md`](notas.md): count the
notes with an empty `destilado` and close with one line: *«N notas sin minar, la más vieja de hace X días.»*
Nothing else — no listing, no proposal.

> **Why here and nowhere else.** A note satisfies the urge to preserve without producing criteria,
> so the debt grows unnoticed and the criterion inside stays inert. The only moment that number
> changes anything is the moment someone is already distilling. Reporting it anywhere else is noise;
> not reporting it is how an inbox rots.

## Idempotency

The ` · ↑` glyph in the project's `index.md` marks what is already promoted. Re-running the skill is
a safe no-op for those clues.

## Edge cases

- **No parent area** (standalone project) → capture in the project only; skip promotion, report it.
- **Clue already in the area** (same symptom) → skip, report.
- **`confirmed` in a project-only file** (e.g. `proyecto.md`) → ignore for promotion.
- **`conjecture`** → never promote.
- **Same clue in the area with different text** (it evolved) → do NOT overwrite; flag for the user's
  manual review and report.
- **No candidates** → report "nothing to promote", no-op.

## Confidence only moves on evidence, and evidence needs a scheduled moment

`conjecture` and `confirmed` are the two ends of a promotion nobody schedules. The kit is strict
about how confidence is **assigned** and silent about when it is **revisited**, so in practice a
`conjecture` written on a Tuesday stays a `conjecture` forever: the friction that would confirm it
happens months later, in a session with other work to do, and nobody goes back.

**Every `conjecture` is written with its promotion condition, in the clue itself.** Not «this may be
confirmed later» but the falsifiable thing that would do it: *«rises to `confirmed` when a monthly
report shows pieces under the ceiling outperform the ones over it»*.

> **A clue with no written promotion condition cannot be promoted**, because there is nothing to
> check against. Finding those and adding the missing condition is usually the largest result of the
> first pass that goes looking.

**And the pass has to be attached to something the project already does** — a monthly report, a
release, a retrospective — never scheduled on its own. A review with no host event is a review that
does not happen. Two rules govern it:

- **Surviving time is not evidence, and surviving a `PRUNE` is not evidence either.** Only a
  measurement moves confidence. This is the same reason `transmute-lore` PRUNE forbids raising it.
- **`refuted` is a real outcome and the clue stays.** A law the evidence contradicted is marked, not
  deleted: a refuted law teaches more than an absent one, and deleting it invites someone to
  rediscover it next year.

## Invariants

- **Capture first in the project; promotion to the area is always gated** — never written silently.
- **Criteria is never invented**; only distilled from what happened.
- **Imported criteria is arbitrated, never adopted** (GRAFT): it was distilled under someone
  else's purpose. No defeats section → no entry.
- **Clues and new filenames follow the lore's established language** (or the user's, if none) —
  never English just because this skill is. Existing files are never renamed here.
- **A note is source, never criteria.** A free note clears the same threshold as anything else, never
  enters verbatim, and is never authoritative.
- **A validity boundary does not travel on its own to the laws that lean on it.** A clue citing an
  older law opens it and inherits its boundary or says why not — and it states its rule by the
  **condition**, not by the category the condition usually holds in. A rule named after the category
  fails exactly where the boundary it never carried had said it would.
- **Correcting a fact is not capturing criteria.** A clue lives in one place; a verifiable fact lives
  in every artifact that cited it and in the source that handed it out. The unit of work is the **set
  of appearances** — sweep the tree before writing, fix them all in one pass, and mark the source
  corpus struck through and dated if it is not edited.
- **A declared junction is written on both sides.** The clue carries `destino:`; the step carries one line naming the clue. A pointer written in only one direction cannot be verified from the other tree, and the two often live in different repositories.
- **Honest confidence:** `confirmed` only after real validation; never inflated to force promotion.
- **Discarded noise is reported**, not silently dropped.
- **A paragraph is a paragraph.** Continuous prose in the clue, the index line's surrounding file
  and any law written here runs to the period, not to column 80. Full statement in `use-lore`.
- **No unseen commit, no push.** The user sees destination and wording before approval; that approval
  covers the corresponding writes and commits in the shown batch.
- **The pass is bracketed by MYCELIUM and is not done until the exit scan closes.** Entry scan when
  it will lean on existing Lore; exit scan over what it wrote, always. Reporting the save as finished
  with a MYCELIUM finding still open — or deferred "to a later pass" — is the failure this bracket
  exists to stop.