@tenkara/afm-linux-arm64 0.0.0-stage → 4.0.0-alpha.6

package/content/questions/adr.questions.yaml

@@ -0,0 +1,14 @@
+questions:
+  - id: status
+    prompt: What is the status of this decision?
+    header: Status
+    recommended: Accepted
+    options:
+      - label: Proposed
+        description: Written down, not yet in force. Pass it as --status proposed.
+      - label: Accepted
+        description: In force today. Pass it as --status accepted.
+      - label: Superseded by ADR-NNNN
+        description: A later decision replaced it; write the new ADR with --supersedes N.
+      - label: Deprecated
+        description: No longer in force and nothing replaced it. Pass it as --status deprecated.

package/content/questions/analyze.questions.yaml

@@ -0,0 +1,12 @@
+questions:
+  - id: remediation
+    prompt: Do you want concrete edits for the top findings?
+    header: Remediation
+    recommended: top-5
+    options:
+      - label: top-5
+        description: Apply the edits for the top 5 findings in severity order, then report what changed and where.
+      - label: top-10
+        description: Same as top-5, for the top 10 findings.
+      - label: report-only
+        description: The report is enough. Nothing is edited and the findings are addressed manually.

package/content/questions/bootstrap-mapping.questions.yaml

@@ -0,0 +1,14 @@
+questions:
+  - id: mapping
+    prompt: Does the component-type to stack mapping drafted for the architecture doc make sense?
+    header: Mapping
+    recommended: All match
+    options:
+      - label: All match
+        description: Materializes the mapping as drafted.
+      - label: Adjust
+        description: One or two entries change; the operator points them out.
+      - label: Some do not apply
+        description: The operator lists the component types the project does not have.
+      - label: Rewrite
+        description: The operator dictates the mapping again.

package/content/questions/bootstrap-rules.questions.yaml

@@ -0,0 +1,10 @@
+questions:
+  - id: rules
+    prompt: Does any inherited hard rule not fit this project? Inalienable rules are never offered.
+    header: Rules
+    recommended: Keep all
+    options:
+      - label: Keep all
+        description: Every opt-out-able rule stays in force.
+      - label: Opt out of some
+        description: The operator names each rule and why; each becomes N/A with that reason.

package/content/questions/bootstrap-stack.questions.yaml

@@ -0,0 +1,23 @@
+questions:
+  - id: stack
+    prompt: Is the stack that afm init reported, layer by layer with its evidence, right?
+    header: Stack
+    recommended: Confirm
+    options:
+      - label: Confirm
+        description: Records every reported layer as decided.
+      - label: Adjust
+        description: Some layers are wrong or missing; the operator names them and the answer is recorded as given.
+      - label: Leave as TBD
+        description: Records [TBD] for the layers; a recommendation works better once the operator also knows what they do not want.
+  - id: modules
+    prompt: Apply every opt-in module detected for the stack? A module is applied whole, so the default is to opt out only what does not fit.
+    header: Modules
+    recommended: All
+    options:
+      - label: All
+        description: Merges each detected module's architecture and rule patches.
+      - label: Some
+        description: Applies all but the modules the operator names; those simply stay out.
+      - label: None
+        description: No module is applied.

package/content/questions/clarify.questions.yaml

@@ -0,0 +1,10 @@
+questions:
+  - id: underspecified
+    prompt: Most categories are Missing and many markers are open. How should clarify proceed?
+    header: Thin spec
+    recommended: respecify
+    options:
+      - label: respecify
+        description: Re-run specify with new input. A spec this thin needs rewriting, not a long question loop.
+      - label: continue
+        description: Keep clarifying anyway, within the limit of 5 questions for this session.

package/content/questions/code-style.questions.yaml

@@ -0,0 +1,12 @@
+questions:
+  - id: code-style
+    prompt: The listed code-style files are house conventions one project observed, not facts of the stack. Apply any? An unmarked item is written nowhere.
+    header: Code style
+    recommended: None
+    options:
+      - label: None
+        description: Nothing applies. The default, because a silent opt-in is the defect this question corrects.
+      - label: Some
+        description: The operator names the files; each is copied verbatim as the project's rule.
+      - label: All
+        description: Every listed file is copied verbatim as the project's rule.

package/content/questions/confirm.questions.yaml

@@ -0,0 +1,12 @@
+questions:
+  - id: restated
+    prompt: Is the restatement above correct?
+    header: Confirmation
+    recommended: Yes, exact
+    options:
+      - label: Yes, exact
+        description: Materializes it as restated.
+      - label: Almost
+        description: A small adjustment; the operator describes the fix.
+      - label: No, rewrite
+        description: The operator dictates it again.

package/content/questions/deliver.questions.yaml

@@ -0,0 +1,23 @@
+questions:
+  - id: outcome
+    prompt: The plan is drafted and verified. What should the delivery do now?
+    header: Outcome
+    recommended: run-to-completion
+    options:
+      - label: run-to-completion
+        description: Approve the plan and execute every task, stopping only at a halt or the push boundary.
+      - label: pause-per-phase
+        description: Approve the plan, execute it, and stop after each phase to ask whether to continue.
+      - label: materialize-only
+        description: Keep the drafted spec, plan and tasks on disk and execute nothing.
+      - label: adjust-or-cancel
+        description: Record no approval. Say what to change in the drafts, or stop here.
+  - id: phase-continue
+    prompt: The phase is done. Continue to the next phase?
+    header: Next phase
+    recommended: continue
+    options:
+      - label: continue
+        description: Run the next phase.
+      - label: stop
+        description: Stop here; re-running deliver resumes at the first open task.

package/content/questions/evolve.questions.yaml

@@ -0,0 +1,15 @@
+# One question per (b) item of the evolve package. Run it once per item:
+#   afm ask evolve --scope <item-slug> --recommend <label>
+# The item's evidence, its recommendation and "what changes if this is wrong" sit in the package the
+# agent shows before asking; the answer applies to that one item only.
+questions:
+  - id: apply
+    prompt: Apply this proposed change to the docs?
+    header: Apply
+    options:
+      - label: Apply
+        description: Apply the change after the gate, exactly as itemized in the package.
+      - label: Skip
+        description: Reject it; the report records the rejection as attempt memory, so it is not proposed again without new evidence.
+      - label: Stage
+        description: Defer it to the next cycle; the report records it as staged.

package/content/questions/export-template-apply.questions.yaml

@@ -0,0 +1,11 @@
+questions:
+  - id: apply
+    prompt: Delete the listed files and write the template marker?
+    header: Apply
+    options:
+      - label: Apply
+        description: Runs the same command with --yes. The deletion is not reversible outside git.
+      - label: Adjust
+        description: Go back to the keep question and review the plan again.
+      - label: Cancel
+        description: Nothing is touched.

package/content/questions/export-template.questions.yaml

@@ -0,0 +1,23 @@
+questions:
+  - id: keep
+    prompt: Which of the artifacts a template normally drops should STAY? Leave empty to keep none.
+    header: Keep
+    multiSelect: true
+    options:
+      - label: prd
+        description: prd.md is product-specific; a template usually drops it.
+      - label: ust
+        description: ust.md holds the product's stories; a template usually drops it.
+      - label: features
+        description: docs/features/ is product work; its tasks are first induced into a reusable shape.
+      - label: afm-version
+        description: A template is not an instance, so the version pin is dropped unless kept.
+  - id: research
+    prompt: What happens to docs/research/, which may hold reusable technical research?
+    header: Research
+    recommended: Keep
+    options:
+      - label: Keep
+        description: The research stays in the template.
+      - label: Delete
+        description: The research goes with the product content.

package/content/questions/gates.questions.yaml

@@ -0,0 +1,27 @@
+questions:
+  - id: dod
+    prompt: Which checks must pass to merge? Pre-check the ones the scan reported as gating merge.
+    header: Merge DoD
+    multiSelect: true
+    options:
+      - label: Test runner
+        description: The project's tests.
+      - label: Type check
+        description: The type checker with no emit.
+      - label: Lint
+        description: The linter or formatter check.
+      - label: Build
+        description: A production build.
+  - id: pre-push
+    prompt: Which checks run before a push? Pre-check the ones the scan reported in a pre-push hook.
+    header: Pre-push
+    multiSelect: true
+    options:
+      - label: Test runner
+        description: The project's tests.
+      - label: Type check
+        description: The type checker with no emit.
+      - label: Lint
+        description: The linter or formatter check.
+      - label: Build
+        description: A production build.

package/content/questions/generalize.questions.yaml

@@ -0,0 +1,13 @@
+# One question per merge of gotchas into an abstract rule:
+#   afm ask generalize --scope <rule-slug>
+questions:
+  - id: merge
+    prompt: Merge the batch of gotchas into the proposed rule and archive the members with tombstones?
+    header: Merge
+    options:
+      - label: Merge as a rule
+        description: Write a hard rule in afm.md section 3 with its 0/1 trigger, then archive the merged gotchas with tombstones.
+      - label: Merge as a principle
+        description: Write the abstraction in afm.md section 1.3 (guidance only, no executable trigger), then archive the merged gotchas with tombstones.
+      - label: Keep separate
+        description: The abstraction loses too much; keep the gotchas as they are and report "not generalizable without loss".

package/content/questions/gotcha.questions.yaml

@@ -0,0 +1,11 @@
+questions:
+  - id: basis
+    prompt: Does this behavior qualify for registration?
+    header: Qualify
+    options:
+      - label: bitten-twice
+        description: Confirmed to have bitten a developer at least twice.
+      - label: documented-sdk
+        description: Documented behavior of a known external SDK or runtime that surprises its users.
+      - label: neither
+        description: No second incidence and no external documentation; nothing is registered.

package/content/questions/init-template.questions.yaml

@@ -0,0 +1,10 @@
+questions:
+  - id: branch
+    prompt: This project comes from an architectural template (docs/.template). How should the interview run?
+    header: Interview
+    recommended: Product only
+    options:
+      - label: Product only
+        description: Runs only product, flows, a short validation step and gotchas. Stack, data model, mapping and rules are inherited.
+      - label: Full interview
+        description: Ignores the marker for this session and runs all seven steps. The marker stays on disk.

package/content/questions/init.questions.yaml

@@ -0,0 +1,28 @@
+questions:
+  - id: harnesses
+    prompt: Which harnesses should the instruction files of this project cover?
+    header: Harnesses
+    multiSelect: true
+    recommended: [claude-code]
+    options:
+      - label: claude-code
+        description: Writes a CLAUDE.md stub that imports AGENTS.md.
+      - label: opencode
+        description: Reads AGENTS.md itself, so no stub is written.
+      - label: agy
+        description: Writes a GEMINI.md stub that imports AGENTS.md.
+      - label: git
+        description: Git hooks only; no instruction file is needed.
+  - id: app-language
+    prompt: In which language does this product show its own users their strings?
+    header: App language
+    recommended: Decide later
+    options:
+      - label: English
+        description: User-facing strings are in English.
+      - label: Portuguese
+        description: User-facing strings are in Portuguese.
+      - label: Spanish
+        description: User-facing strings are in Spanish.
+      - label: Decide later
+        description: Records [TBD] in the PRD; the language migration stops and asks.

package/content/questions/plan.questions.yaml

@@ -0,0 +1,14 @@
+questions:
+  - id: open-markers
+    prompt: The spec has open NEEDS CLARIFICATION markers. How should the plan proceed?
+    header: Markers
+    recommended: clarify-first
+    options:
+      - label: clarify-first
+        description: Run the structured clarify scan first. It records dated answers in the spec, then planning resumes.
+      - label: resolve-inline
+        description: Quick fallback. Answer each marker in free text now; no Clarifications section is written.
+      - label: keep-going
+        description: Not recommended. The plan inherits the markers and the tasks step refuses to run until they are resolved.
+      - label: cancel
+        description: Go back to the spec and plan nothing yet.

package/content/questions/refactor.questions.yaml

@@ -0,0 +1,23 @@
+questions:
+  - id: adr
+    prompt: Which of the inferred decisions still load-bear today and become a retroactive ADR? Would someone need a doc to explain why if it were swapped tomorrow?
+    header: ADRs
+    recommended: None
+    options:
+      - label: None
+        description: No retroactive ADR; a dead decision never becomes one later.
+      - label: Some
+        description: The operator names the decisions; each becomes an accepted retroactive ADR.
+      - label: All
+        description: Every listed candidate becomes an accepted retroactive ADR.
+  - id: gotcha-seeds
+    prompt: Which gotcha seeds of the detected stacks has the team here already been bitten by? Seeds are candidates, not active entries.
+    header: Gotchas
+    recommended: None
+    options:
+      - label: None
+        description: No seed is activated.
+      - label: Some
+        description: The operator names the seeds; each becomes its own gotcha file.
+      - label: All
+        description: Every seed is confirmed as already lived here and becomes its own gotcha file.

package/content/questions/reflect.questions.yaml

@@ -0,0 +1,13 @@
+# One question per refinement of a doc that guided badly in the session:
+#   afm ask reflect --scope <item-slug>
+questions:
+  - id: refinement
+    prompt: Refine this doc as proposed?
+    header: Refinement
+    options:
+      - label: Apply
+        description: Apply the refinement (rewrite, added trigger, or disambiguation) exactly as itemized.
+      - label: Report only
+        description: Do not edit the doc; keep the finding as a suggestion in the report.
+      - label: Skip
+        description: Reject it; the report records the rejection so the finding is not proposed again without new evidence.

package/content/questions/remediate.questions.yaml

@@ -0,0 +1,27 @@
+# One pair of questions per recurring failure (the scope is the sig= as a slug):
+#   afm ask remediate --scope <sig>
+questions:
+  - id: artifact
+    prompt: Which durable artifact should this failure become?
+    header: Artifact
+    options:
+      - label: Guardrail
+        description: A check a command can run with no judgment; takes precedence over the other two.
+      - label: Procedure
+        description: A repeatable sequence of steps with a 0/1 gate per step and a start trigger.
+      - label: Learning
+        description: A conceptual lesson whose value is in its cause.
+      - label: Not now
+        description: Leave the failure open; it waits for recurrence or for a user correction.
+  - id: surface
+    prompt: For a guardrail, where is the check installed?
+    header: Surface
+    options:
+      - label: Linter
+        description: The linter config the project already runs.
+      - label: CI
+        description: The CI workflow the project already runs.
+      - label: Git hook
+        description: A git hook (afm install git runs the gate there).
+      - label: Not a guardrail
+        description: The artifact is a procedure, a learning or nothing, so no check is installed.

package/content/questions/restructure.questions.yaml

@@ -0,0 +1,15 @@
+# One question per staleness, findability or dead-gotcha finding:
+#   afm ask restructure --scope <item-slug>
+questions:
+  - id: finding
+    prompt: What should be done with this finding?
+    header: Finding
+    options:
+      - label: Update the doc
+        description: Read the current code, then update the stale doc (a proposal, never an auto-fix).
+      - label: Relocate
+        description: Move the information to where it is expected, or add a pointer there; a loading-strategy ADR for a tiering finding.
+      - label: Archive
+        description: Comment the dead entry out as a tombstone; nothing is deleted.
+      - label: Leave as is
+        description: The doc is still right; the report records the review.

package/content/questions/rf-mapping.questions.yaml

@@ -0,0 +1,12 @@
+questions:
+  - id: rf
+    prompt: Which PRD requirement does this user story implement?
+    header: RF mapping
+    recommended: New RF
+    options:
+      - label: New RF
+        description: Drafts the next RF in the PRD from the story.
+      - label: Existing RF
+        description: The operator names the number or the title.
+      - label: Not yet
+        description: Records [TBD]; decided later.

package/content/questions/rule-scope.questions.yaml

@@ -0,0 +1,12 @@
+questions:
+  - id: scope
+    prompt: Where does the rule enter?
+    header: Rule scope
+    recommended: forward-only
+    options:
+      - label: universal
+        description: Section 3, applies to all code including legacy. May produce a large cleanup change.
+      - label: forward-only
+        description: Section 3.1, new code and files touched from today on. Legacy debt is tracked, not blocking.
+      - label: cancel
+        description: Nothing is written; the decision needs more thought.

package/content/questions/rule.questions.yaml

@@ -0,0 +1,12 @@
+questions:
+  - id: surface
+    prompt: Where does this trigger run?
+    header: Surface
+    recommended: pre-commit
+    options:
+      - label: pre-commit
+        description: Blocks every commit, including one made outside an agent session. Costs the trigger's runtime on each commit.
+      - label: ci
+        description: Blocks the merge, not the local commit. Only honest when the project already has CI.
+      - label: agent
+        description: Stays in the doc and runs by judgment. Honest for a heuristic trigger, not for a precise one nobody automated.

package/content/questions/specify.questions.yaml

@@ -0,0 +1,23 @@
+questions:
+  - id: heuristic
+    prompt: The change is borderline for a feature folder. Open one, or go straight to the loop?
+    header: Feature?
+    recommended: open-feature
+    options:
+      - label: open-feature
+        description: Create docs/features/NNN-slug with a spec, then plan and tasks. Best when the change spans files or has unknowns.
+      - label: straight-to-loop
+        description: Skip the folder and run the RED, GREEN, REFACTOR, COMMIT loop of core/afm.md section 2 once.
+  - id: us-link
+    prompt: Which user story does this feature correspond to?
+    header: Linked US
+    recommended: candidate
+    options:
+      - label: candidate
+        description: The story the scan matched in docs/ust.md. Confirms the link.
+      - label: other-existing
+        description: A different existing story. The operator gives its number.
+      - label: create-first
+        description: Write a new story with a Gherkin criterion in docs/ust.md before the spec.
+      - label: later
+        description: No story yet. The spec records a NEEDS CLARIFICATION marker to link it.

package/content/questions/update-artifacts.questions.yaml

@@ -0,0 +1,10 @@
+questions:
+  - id: artifact-language
+    prompt: Migrate the artifacts (docs, code comments, test names) to English?
+    header: Artifacts
+    recommended: Migrate to English
+    options:
+      - label: Migrate to English
+        description: Artifacts move to English and stop paying the token cost of a second language in every context load.
+      - label: Keep the current language
+        description: Nothing moves. The choice is recorded so the next update does not ask again.

package/content/questions/update-strings.questions.yaml

@@ -0,0 +1,14 @@
+questions:
+  - id: app-language
+    prompt: In which language does this product show its own users their strings? The PRD records none yet.
+    header: App language
+    recommended: Decide later
+    options:
+      - label: English
+        description: User-facing strings are English; nothing is excluded from the artifact migration.
+      - label: Portuguese
+        description: User-facing strings are Portuguese and stay out of the migration.
+      - label: Spanish
+        description: User-facing strings are Spanish and stay out of the migration.
+      - label: Decide later
+        description: Records [TBD]; the artifact language migration does not run until it is set.

package/content/questions/update.questions.yaml

@@ -0,0 +1,10 @@
+questions:
+  - id: apply
+    prompt: Apply the migrations the dry run listed and move the version pin?
+    header: Update
+    recommended: Apply
+    options:
+      - label: Apply
+        description: Applies every migration in order, proves each one, then moves the pin. A failed migration keeps the pin where it was.
+      - label: Not now
+        description: Nothing is applied and the pin stays; the dry run can be repeated later.

package/content/questions/verify.questions.yaml

@@ -0,0 +1,9 @@
+questions:
+  - id: reviewed
+    prompt: Did you read this document yourself and stand behind it?
+    header: Reviewed
+    options:
+      - label: Yes, I read it
+        description: Stamps the verification under your name.
+      - label: No
+        description: Nothing is stamped; a stamp asserts that a person read the content.

package/content/roles/executor.md

@@ -0,0 +1,18 @@
+---
+role: executor
+description: Writer of one bounded change. Makes the edit its brief names, test first, inside the files the brief grants, and reports what changed; dispatched with a brief.
+capabilities: read, search, write, shell
+---
+You are an executor. The message that dispatched you is your brief: follow it.
+
+You make the change the brief names, and only that change.
+
+- Touch only the files the brief grants. Another file you need is a question for the caller, not an edit.
+- Test first: a failing test (or a type that does not compile yet), then the smallest change that
+  makes it pass, then the refactor. Run the tests and the type check before you report.
+- Reuse what exists before you add a helper. Add no option, hook or abstraction the brief did not ask for.
+- Never print, write or commit a secret.
+- Never push, and never commit unless the brief says to.
+
+Reply with the files you changed, the checks you ran with their exact result, and anything you left
+undone or doubt.

package/content/roles/explorer.md

@@ -0,0 +1,22 @@
+---
+role: explorer
+description: Read-only investigator. Answers one question from the code, the docs or the web, cites what it read, and changes nothing; dispatched with a brief.
+steps: 60
+capabilities: read, search, web
+mcpTools: approve, config, detect, doctor, failures_promotable, feature_lint, feature_status, gate, index, lang, next_id, path, policy, preflight, version
+cliDoor: false
+---
+You are an explorer. The message that dispatched you is your brief: follow it.
+
+You only read. You never edit a file, run a command that changes state, or commit.
+
+- Read only what the question needs: the sections you are about to use, not whole trees.
+- Cite every claim: a path with the line, or a source URL with the literal quote. A claim with no
+  citation is a guess, and you label it a guess.
+- Never invent a path, a line number, a URL or a quote. If you did not read it, you do not cite it.
+- Say what you could not find. Absence is a result.
+
+You have at most 60 steps. Write the answer whole, not a step at a time. If you run out, reply with
+what you have and what is still missing.
+
+Reply with the answer first, then the evidence, then the gaps.

package/content/roles/reviewer.md

@@ -0,0 +1,23 @@
+---
+role: reviewer
+description: Blind auditor. Checks one piece of work it did not write against its sources and rules, and returns a verdict with evidence; dispatched with a brief.
+capabilities: read, search, web
+mcpTools: approve, config, detect, doctor, failures_promotable, feature_lint, feature_status, gate, index, lang, next_id, path, policy, preflight, version
+cliDoor: false
+---
+You are a reviewer. The message that dispatched you is your brief: follow it.
+
+You audit work you did not write. You read it and the sources or rules it answers to. You never
+write a fix.
+
+- Judge against the rules and sources the brief names, not against taste.
+- Verify, do not trust: open each cited path, line or quote and confirm it says what the work claims.
+- Run the checks the brief lists that the `afm` tools offer (the gate, the doctor, the index), alone and one
+  at a time, and report their exact output. You have no shell: a check that needs one is a check you did
+  not run, and you say so.
+- Report a finding only with its evidence: the path and line, the rule it breaks, and the concrete
+  input or state that fails. A suspicion with no evidence is not a finding.
+- Say what you did not check.
+
+End with one verdict line: PASS when no finding stands, FAIL otherwise, followed by the findings
+most severe first.

package/content/rubrics/enum-vs-union-vs-branded.md

@@ -0,0 +1,40 @@
+---
+type: rubric
+description: Chooses between an ORM enum, a literal union, a branded type and a parser schema.
+load: warm
+fires_on: file-shape
+trigger_ext: '.ts .tsx'
+trigger_grep: '(^[[:space:]]*(export[[:space:]]+)?(const[[:space:]]+)?enum[[:space:]]+[A-Za-z_]|\([[:space:]]*[a-zA-Z_][A-Za-z0-9_]*:[[:space:]]*string[[:space:]]*,[[:space:]]*[a-zA-Z_][A-Za-z0-9_]*:[[:space:]]*string[[:space:]]*[,)])'
+fires_when: 'a TS `enum` is declared, or a signature takes two adjacent `string` parameters'
+---
+
+# Rubric — enum vs literal union vs branded type vs Zod schema
+
+## Decision table
+
+| Case | Choice | Anti-pattern |
+| --- | --- | --- |
+| Value exists in the DB (status, role, plan) | **ORM enum** (Prisma enum, etc) — the only path that survives `generate` | Pure TS enum that mirrors the ORM enum — duplication |
+| ≤ 5 closed values, used only in code | **Literal union** (`"latest" \| "next" \| "beta"`) | Pure TS enum — produces transpiled waste, not tree-shakeable |
+| Open string with a rule (user input, free dist-tag) | **Parser schema** (Zod) + parse at the boundary | Validation inside the domain (violates hard rule 16) |
+| Primitive with a semantic invariant (sha256, userId ≠ sessionId, currency cents) | **Branded type** (`type Hash = string & { __brand: "Hash" }`) | Raw `string` — loses the check at the call site |
+| Opaque value from an external SDK (Stripe price id) | SDK type + Zod at the boundary | Re-type as branded — duplicates the SDK |
+
+## When a branded type wins
+
+- A function takes two strings with different meanings (`copy(from: string, to: string)`). A branded type stops you from swapping the order.
+- Hash, ID, currency in cents, timestamp in ms vs s. A branded type makes the conversion explicit.
+- Different domain IDs (UserId vs SessionId vs OrgId). A branded type stops you from passing a UserId where the code asked for an OrgId.
+
+## When a branded type does not pay off
+
+- A string that goes to a log, a UI, or the network. The reader gains nothing.
+- The type already comes from the SDK as an opaque string. Re-typing it just duplicates the SDK.
+- The function has one parameter. There is no ambiguity to resolve.
+
+## Anti-examples
+
+- ❌ `enum Plan { FREE = "FREE", PRO = "PRO" }` in TS when Prisma already has `enum Plan { FREE, PRO }`. Use the Prisma one directly.
+- ❌ `type DistTag = string` that accepts anything. Use a literal union if the set is closed, or Zod if it is open with a rule.
+- ❌ `copy(src: string, dst: string)` called by mistake as `copy(dst, src)`. Branded `SrcPath` and `DstPath` types fix this.
+- ❌ Branding every `string` "for consistency". This adds overhead with no check gained.