@tenkara/afm-linux-arm64 4.0.0-alpha.8 → 4.0.0-alpha.9

package/plugin/opencode/skills/afm-remediate/SKILL.md

@@ -10,7 +10,7 @@ description: |
 
 > **Questions in this host.** `afm ask <op>` prompts only in a terminal, and your shell tool has none: it exits 2. Run `afm ask <op> --json` instead and put each pending question to the operator with the host's question tool when it has one, and otherwise in chat as a numbered list: the `prompt`, then the `options` with their descriptions, the recommended one first and marked. Wait for the answer. Then record each choice with `afm answer <op> <id> <label>` (one label per selected option). Run `afm ask <op>` again: `all questions answered` means the op may go on.
 
-Atomic skill of AFM. The canonical procedure is the op file that `afm path ops/remediate.md` prints.
+> **Procedure.** Run `afm read ops/remediate.md` and follow it; read an on-demand section when its condition holds.
 
 ## When NOT to activate
 
@@ -26,16 +26,14 @@ Use `afm.md § 5.1` for an in-task retry at the moment of the error. Use `afm-go
 
 ## Procedure
 
-Read the op (`afm path ops/remediate.md`) end to end and follow it literally. It includes the promotion gate (#5): 1 user correction OR at least 2 mechanical occurrences promote a failure. A transient failure does not promote. It also includes classification through the rubric `rubrics/failure-classification.md` (`afm path rubrics/failure-classification.md`). For each delta, propose the artifact (procedure or learning) and cite the source `sig=` (hard rule 19). Ask the artifact question with `afm ask remediate --scope <sig>`, materialize the result, close the signature with `afm failures close --sig <sig> --as remediated`, and report it (#6).
+The op includes the promotion gate (#5): 1 user correction OR at least 2 mechanical occurrences promote a failure. A transient failure does not promote. It also includes classification through the rubric `rubrics/failure-classification.md` (`afm path rubrics/failure-classification.md`). For each delta, propose the artifact (procedure or learning) and cite the source `sig=` (hard rule 19). Ask the artifact question with `afm ask remediate --scope <sig>`, materialize the result, close the signature with `afm failures close --sig <sig> --as remediated`, and report it (#6).
 
 ## Invariant principles
 
-The single canonical source is `PRINCIPLES.md` (`afm path PRINCIPLES.md`). See in particular #3 (CRITIC corollary — recognition by tool, not self-judgment). See also #5 (do not promote a failure without recurrence or an oracle) and #6 (propose only, the human approves).
+Most relevant here: #3 (CRITIC corollary — recognition by tool, not self-judgment). See also #5 (do not promote a failure without recurrence or an oracle) and #6 (propose only, the human approves).
 
 ## Continuous doctrine
 
-The `reconcile` skill owns passive mode, and it is always on. It reads `afm failures promotable` at the end of the turn and can propose remediation with no explicit command. The `evolve` cycle uses the failure events as evidence for `reflect`, toward a final remediation. This skill is the active record of the loop.
+Passive mode (`afm-reconcile`) is always on. It reads `afm failures promotable` at the end of the turn and can propose remediation with no explicit command. The `afm-evolve` cycle uses the failure events as evidence for `afm-reflect`, toward a final remediation. This skill is the active record of the loop.
 
-## Version
-
-Content version: `afm version` prints it.
+**Principles and version.** `afm path PRINCIPLES.md` (universals §1-8 apply). `afm version` prints the version; history: `afm path CHANGELOG.md`.

package/plugin/opencode/skills/afm-restructure/SKILL.md

@@ -10,9 +10,9 @@ description: |
 
 > **Questions in this host.** `afm ask <op>` prompts only in a terminal, and your shell tool has none: it exits 2. Run `afm ask <op> --json` instead and put each pending question to the operator with the host's question tool when it has one, and otherwise in chat as a numbered list: the `prompt`, then the `options` with their descriptions, the recommended one first and marked. Wait for the answer. Then record each choice with `afm answer <op> <id> <label>` (one label per selected option). Run `afm ask <op>` again: `all questions answered` means the op may go on.
 
-This is a mechanism skill of AFM. The canonical procedure is the op file that `afm path ops/restructure.md` prints.
+> **Procedure.** Run `afm read ops/restructure.md` and follow it; read an on-demand section when its condition holds.
 
-> **Carve-out (does not overlap existing ops):** `diagnose` A1 finds a **dead reference** (the path does not exist). `restructure` staleness finds a path that **exists but changed** while the doc did not. `reconcile` adds **missing** information. `restructure` relocates information that **exists but sits in the wrong place**. `reflect` targets **clarity**. `restructure` targets **location and freshness**. `evolve` is the **orchestrator** that composes this skill when `diagnose` flags staleness or bloat.
+> **Carve-out (does not overlap existing ops):** `afm-diagnose` A1 finds a **dead reference** (the path does not exist). `restructure` staleness finds a path that **exists but changed** while the doc did not. `afm-reconcile` adds **missing** information. `restructure` relocates information that **exists but sits in the wrong place**. `afm-reflect` targets **clarity**. `restructure` targets **location and freshness**. `afm-evolve` is the **orchestrator** that composes this skill when `afm-diagnose` flags staleness or bloat.
 >
 > **Maturity (honest YAGNI):** the actionable core today is **staleness** (from git) plus **findability**. **Temperature tiering** (always-hot vs on-demand) is an **opt-in** ADR proposal, only for a doc that has actually outgrown its size. Small docs do not need it.
 
@@ -20,7 +20,7 @@ This is a mechanism skill of AFM. The canonical procedure is the op file that `a
 
 This is a disambiguation guide for a skill that has already activated. It does not gate activation, so it stays in the body, not in the resident listing.
 
-A path that does not exist belongs to `afm-diagnose` (A1). Staleness means the path exists but changed. Information never documented belongs to `reconcile` → `afm-gotcha` or `afm-rule`. An ambiguous doc belongs to `afm-reflect`. Merging gotchas belongs to `afm-generalize`. The full cycle belongs to `afm-evolve`.
+A path that does not exist belongs to `afm-diagnose` (A1). Staleness means the path exists but changed. Information never documented belongs to passive mode (`afm-reconcile`) → `afm-gotcha` or `afm-rule`. An ambiguous doc belongs to `afm-reflect`. Merging gotchas belongs to `afm-generalize`. The full cycle belongs to `afm-evolve`.
 
 ## Pre-check
 
@@ -30,25 +30,23 @@ A path that does not exist belongs to `afm-diagnose` (A1). Staleness means the p
 
 ## Procedure
 
-Read the op (`afm path ops/restructure.md`) end to end. Follow it literally. Use these five steps.
+Use these five steps.
 
 1. **Staleness scan.** `afm doctor --json` runs it (findings with axis `staleness` and `dead-gotcha`); read them. The git trigger fires in two cases. First case: a path cited in the doc has a later last commit than the doc. Second case: the doc has been stale for more than N commits. A hit is a candidate, not a verdict. The scan never rewrites the doc on its own.
-2. **Findability.** Relocate or cross-reference information that exists but sits buried or in the wrong doc. Cite both locations. Route information that is genuinely missing to `reconcile`.
+2. **Findability.** Relocate or cross-reference information that exists but sits buried or in the wrong doc. Cite both locations. Route information that is genuinely missing to passive mode (`afm-reconcile`).
 3. **Temperature partition.** Propose a hot/on-demand loading strategy as an opt-in ADR. Do this only when a doc has outgrown its size. Preserve 100% of the content.
-4. **Its own gate.** This gate is load-bearing and earned, one `afm ask restructure --scope <item-slug>` per finding. It follows the **shared-proposal discipline** in `evolve.md` (`afm path ops/evolve.md`), instead of a duplicate copy of that discipline. `evolve` suppresses this gate when it runs.
-5. **Record.** Write the result to `docs/evolution/NNN-<date>.md`. Suggest `promote` if the finding generalizes.
+4. **Its own gate.** This gate is load-bearing and earned, one `afm ask restructure --scope <item-slug>` per finding. It follows the **shared-proposal discipline** in `evolve.md` (`afm path ops/evolve.md`), instead of a duplicate copy of that discipline. `afm-evolve` suppresses this gate when it runs.
+5. **Record.** Write the result to `docs/evolution/NNN-<date>.md`. Suggest `afm-promote` if the finding generalizes.
 
 ## Invariant principles
 
-The single canonical source is `PRINCIPLES.md` (`afm path PRINCIPLES.md`). Universal principles §1-8 apply here. Four principles matter most for this skill.
+Most relevant here:
 
 - #2: get git evidence before you propose a change.
 - #3: staleness needs an executable git trigger.
-- #4/#5: missing product content becomes `[TBD]` or goes to `reconcile`. Never invent it.
+- #4/#5: missing product content becomes `[TBD]` or goes to passive mode (`afm-reconcile`). Never invent it.
 - #6/#8: self-check the work, then pass an earned gate.
 
 **No new principle here.** `restructure` is a composed materialization. The doctrine lives in the op file.
 
-## Version
-
-Content version: `afm version` prints it.
+**Principles and version.** `afm path PRINCIPLES.md` (universals §1-8 apply). `afm version` prints the version; history: `afm path CHANGELOG.md`.

package/plugin/opencode/skills/afm-rule/SKILL.md

@@ -9,9 +9,10 @@ description: |
 
 > **Questions in this host.** `afm ask <op>` prompts only in a terminal, and your shell tool has none: it exits 2. Run `afm ask <op> --json` instead and put each pending question to the operator with the host's question tool when it has one, and otherwise in chat as a numbered list: the `prompt`, then the `options` with their descriptions, the recommended one first and marked. Wait for the answer. Then record each choice with `afm answer <op> <id> <label>` (one label per selected option). Run `afm ask <op>` again: `all questions answered` means the op may go on.
 
-Atomic skill of `afm`. The canonical procedure is the op `afm path ops/rule`. The CLI owns the number, the
-rule file, the index line and the runner skeleton, and refuses a rule with no honest trigger form. This
-skill keeps only the judgment.
+> **Procedure.** Run `afm read ops/rule.md` and follow it; read an on-demand section when its condition holds.
+
+The CLI owns the number, the rule file, the index line and the runner skeleton, and refuses a rule with no
+honest trigger form. This skill keeps only the judgment.
 
 ## When NOT to activate
 
@@ -38,9 +39,11 @@ that already exist.
 
 ## Invariant principles
 
-Single canonical source: `afm path PRINCIPLES`. Universals §1-8 apply. Note especially #3 (a hard rule needs
+Most relevant here: #3 (a hard rule needs
 a mechanical trigger, or it is a principle instead) and #6 (autonomy-first: materialize the change and
 report it).
 
 Passive mode (`afm-reconcile`) is always on and can propose `afm-rule` when it detects the signal "the user
 corrected an approach with a reusable rule".
+
+**Principles and version.** `afm path PRINCIPLES.md` (universals §1-8 apply). `afm version` prints the version; history: `afm path CHANGELOG.md`.

package/plugin/opencode/skills/afm-specify/SKILL.md

@@ -9,11 +9,11 @@ description: |
 
 > **Questions in this host.** `afm ask <op>` prompts only in a terminal, and your shell tool has none: it exits 2. Run `afm ask <op> --json` instead and put each pending question to the operator with the host's question tool when it has one, and otherwise in chat as a numbered list: the `prompt`, then the `options` with their descriptions, the recommended one first and marked. Wait for the answer. Then record each choice with `afm answer <op> <id> <label>` (one label per selected option). Run `afm ask <op>` again: `all questions answered` means the op may go on.
 
-An atomic skill. The procedure lives in the op: read it with `afm path ops/specify.md`, end to end, and follow it literally.
+> **Procedure.** Run `afm read ops/specify.md` and follow it; read an on-demand section when its condition holds.
 
 ## When NOT to activate
 
-A trivial change (no feature folder needed) goes straight to the `afm.md § 2` loop. A full end-to-end delivery is `deliver`, which composes this op.
+A trivial change (no feature folder needed) goes straight to the `afm.md § 2` loop. A full end-to-end delivery is `afm-deliver`, which composes this op.
 
 ## Pre-check
 
@@ -25,12 +25,10 @@ The number comes from `afm next-id feature`, never by hand. What is left to you
 
 ## Invariant principles
 
-Single canonical source: `afm path PRINCIPLES.md`. Universals §1-8 apply. In particular #2 (discover-first: compute the heuristic and the US from the scan), #5 (never invent a success criterion) and #6 (autonomy-first).
+Most relevant here: #2 (discover-first: compute the heuristic and the US from the scan), #5 (never invent a success criterion) and #6 (autonomy-first).
 
 ## Continuous doctrine
 
-Passive mode is the always-on `reconcile` skill. This skill covers only the opening of the feature.
+Passive mode (`afm-reconcile`) is always on. This skill covers only the opening of the feature.
 
-## Version
-
-`afm version`. History: `afm path CHANGELOG.md`.
+**Principles and version.** `afm path PRINCIPLES.md` (universals §1-8 apply). `afm version` prints the version; history: `afm path CHANGELOG.md`.

package/plugin/opencode/skills/afm-tasks/SKILL.md

@@ -7,28 +7,22 @@ description: |
 
 # AFM — Tasks
 
-An atomic skill. The procedure lives in the op: read it with `afm path ops/tasks.md`, end to end, and follow it literally.
+> **Procedure.** Run `afm read ops/tasks.md` and follow it; read an on-demand section when its condition holds.
 
 ## When NOT to activate
 
-There is no `plan.md` yet: run `afm-plan` first. An end-to-end delivery is `deliver`, which composes this op.
+There is no `plan.md` yet: run `afm-plan` first. An end-to-end delivery is `afm-deliver`, which composes this op.
 
 ## Pre-check
 
 Run `afm preflight` (exit 3: stop and suggest `afm-init` or `afm-refactor`). Run `afm feature status <NNN> --json`: a non-empty `blockers` is an open `[NEEDS CLARIFICATION:]` in the plan. That is a hard refusal with no override, not a question.
 
-## Procedure
+## Principles
 
-Create the file with the generator (`afm new feature-tasks --feature NNN-slug`), then add every task with `afm task add <NNN> --kind <k> --text <t>`: setup tasks, then for each spec scenario a red task (`--scenario N`) and the green task that closes it (`--closes Txxx`), an optional refactor, the validation task of each plan boundary (`--validates <boundary name>`), and one reconcile task, last. Never write a task by hand: the tasks live in the frontmatter `tasks:` list, and the CLI assigns the id and validates the item. Mark `--parallel` only where a task does not depend on the one before it; a green never is. Give every task a `US-NNN` or `RF-NN` (`--refs`). The CLI refuses an item that breaks a lint rule. Then run `afm feature lint <NNN>` and fix what it reports until it exits 0: a missing task with `afm task add`, a wrong field or kind with `afm task set <NNN> <Txxx> --<field> <value>` (`--clear <field>` clears one), a task that should not exist with `afm task remove <NNN> <Txxx>`. Never edit the YAML by hand. The reconcile task closes the `status:` keys; close each task with `afm task done`. Autonomy-first: write and report.
-
-## Invariant principles
-
-Single canonical source: `afm path PRINCIPLES.md`. Universals §1-8 apply. In particular #5 (every task traces to a US or RF) and rule 1 (TDD: no green task without the red task it closes).
+Most relevant here: #5 (every task traces to a US or RF) and rule 1 (TDD: no green task without the red task it closes).
 
 ## Continuous doctrine
 
-Passive mode is the always-on `reconcile` skill. This skill covers only the task list.
-
-## Version
+Passive mode (`afm-reconcile`) is always on. This skill covers only the task list.
 
-`afm version`. History: `afm path CHANGELOG.md`.
+**Principles and version.** `afm path PRINCIPLES.md` (universals §1-8 apply). `afm version` prints the version; history: `afm path CHANGELOG.md`.

package/plugin/opencode/skills/afm-update/SKILL.md

@@ -9,8 +9,9 @@ description: |
 
 > **Questions in this host.** `afm ask <op>` prompts only in a terminal, and your shell tool has none: it exits 2. Run `afm ask <op> --json` instead and put each pending question to the operator with the host's question tool when it has one, and otherwise in chat as a numbered list: the `prompt`, then the `options` with their descriptions, the recommended one first and marked. Wait for the answer. Then record each choice with `afm answer <op> <id> <label>` (one label per selected option). Run `afm ask <op>` again: `all questions answered` means the op may go on.
 
-This is the sync skill of `afm`. The canonical procedure is the op `afm path ops/update`. The CLI runs the
-codemod registry, proves each op and moves the pin. This skill keeps the judgment.
+> **Procedure.** Run `afm read ops/update.md` and follow it; read an on-demand section when its condition holds.
+
+The CLI runs the codemod registry, proves each op and moves the pin. This skill keeps the judgment.
 
 > **Carve-out (does not overlap existing ops):** `afm-init` and `afm-refactor` **create** the instance
 > (bootstrap). `update` brings an **existing** instance forward, the path that `afm-refactor` refuses.
@@ -44,15 +45,20 @@ the run. A pin **ahead** of the binary is an anomaly: report it, never roll it b
 4. **Language migration** (when the instance is not English): read `prd.md` § 11.1 FIRST and derive the
    excluded scope from it, and only then read a file. `[TBD]` there stops the step and asks
    `afm ask update-strings`. It never picks a language. The artifacts question is
-   `afm ask update-artifacts`.
+   `afm ask update-artifacts`. On migrate, run the rewrite as one orchestrated batch through
+   parallel subagents through the `task` tool, with a light model per agent (the smallest model of the configured provider) for the rewrite and the loss
+   check. Escalate only a flagged file to a capable model. The session model keeps the excluded scope and
+   the final gate.
 5. Post-conditions: `afm index --check` returns 0 and the plugin boundary stays clean. Report in chat what
    migrated and what stayed pending. Under `afm-evolve`, feed it to `docs/evolution/`.
 
 ## Invariant principles
 
-Single canonical source: `afm path PRINCIPLES`. Universals §1-8 apply. Follow #2 (discover-first): the proof of
+Most relevant here: #2 (discover-first): the proof of
 need is the grep that shows what is missing. Follow #4/#5: materialize only what the plugin already provides
 ready-made, and never invent missing product content. Follow #6 (autonomy-first with a gate). Bright line
 #7 applies: only **read** the plugin, and write only to the instance.
 
 **No new principle here.** `update` is composed materialization. The doctrine lives in the op file.
+
+**Principles and version.** `afm path PRINCIPLES.md` (universals §1-8 apply). `afm version` prints the version; history: `afm path CHANGELOG.md`.

package/plugin/opencode/skills/afm-verify/SKILL.md

@@ -9,7 +9,7 @@ description: |
 
 > **Questions in this host.** `afm ask <op>` prompts only in a terminal, and your shell tool has none: it exits 2. Run `afm ask <op> --json` instead and put each pending question to the operator with the host's question tool when it has one, and otherwise in chat as a numbered list: the `prompt`, then the `options` with their descriptions, the recommended one first and marked. Wait for the answer. Then record each choice with `afm answer <op> <id> <label>` (one label per selected option). Run `afm ask <op>` again: `all questions answered` means the op may go on.
 
-Atomic skill of `afm`. The canonical procedure is the op `afm path ops/verify`.
+> **Procedure.** Run `afm read ops/verify.md` and follow it; read an on-demand section when its condition holds.
 
 ## When not to activate
 
@@ -30,4 +30,6 @@ agent actor. Report the tier that resulted and what it means.
 
 ## Invariant principles
 
-Single canonical source: `afm path PRINCIPLES`. Universals §1-8 apply. #5 is load-bearing here.
+Most relevant here: #5 is load-bearing.
+
+**Principles and version.** `afm path PRINCIPLES.md` (universals §1-8 apply). `afm version` prints the version; history: `afm path CHANGELOG.md`.