devrites 3.0.5 → 3.0.6

package/pack/generated/codex/skills/devrites-lib/reference/standards/developer-experience.md

@@ -1,8 +1,8 @@
 # Developer experience
 
-When a change ships a surface another engineer has to *use* — a public API, a CLI, an SDK
+When a change ships a surface another engineer has to *use* (a public API, a CLI, an SDK
 or library, a webhook, a config/env contract, an error message, or the getting-started path
-that introduces all of them — the developer using it is a user, and their experience is part
+that introduces all of them) the developer using it is a user, and their experience is part
 of the change. Code that compiles and passes its tests can still strand the next developer at
 a cryptic error, a getting-started snippet that doesn't run, or an endpoint whose shape you
 have to read the source to learn. Un-tested DX is a claim, the same way un-run code is a claim.
@@ -10,9 +10,9 @@ have to read the source to learn. Un-tested DX is a claim, the same way un-run c
 This rule is the developer-facing counterpart to [`performance.md`](performance.md): perf says
 *measure the speed before you assert it*; this says *measure the experience before you assert
 it*. It pairs with the [`devrites-api-interface`](../../../devrites-api-interface/SKILL.md)
-skill (which shapes the contract) — this rule **proves** the shape is usable.
+skill (which shapes the contract). This rule **proves** the shape is usable.
 
-## Scope — when this applies
+## Scope: when this applies
 
 Conditional, like [`performance.md`](performance.md) and [`observability.md`](observability.md).
 It applies when the diff changes a **developer-facing surface**:
@@ -23,55 +23,55 @@ It applies when the diff changes a **developer-facing surface**:
 - a **webhook**, event payload, or integration contract;
 - a **config / env-var** interface a consumer must set;
 - an **error message, exit code, or failure response** a developer reads to recover;
-- the **getting-started path** — README, install steps, quickstart, the first-run docs.
+- the **getting-started path**. README, install steps, quickstart, the first-run docs.
 
 Skip it for pure-internal refactors, private helpers, app-only UI (that's
 [`devrites-frontend-craft`](../../../devrites-frontend-craft/SKILL.md) /
 `devrites-frontend-reviewer`), docs-only typo fixes, and config that no external consumer
-touches. Don't DX-review a change with no developer-facing surface — the same scope discipline
+touches. Don't DX-review a change with no developer-facing surface: the same scope discipline
 as the rest of the conditional rules. End-user UX is a different axis; this rule is about the
 *developer* consuming the surface.
 
-## The boomerang — predict at plan, measure at prove, reconcile at seal
+## The boomerang: predict at plan, measure at prove, reconcile at seal
 
 DevRites already runs a predict-then-prove spine (the vetted `test-plan.md` coverage target at
 `$rite-vet`, proven at `$rite-prove`, gated at `$rite-seal`). DX rides the same spine, and the
 gap between the two ends is the signal:
 
-1. **Predict** — at `$rite-vet`, when a developer-facing surface is in scope, score the *planned*
+1. **Predict:** at `$rite-vet`, when a developer-facing surface is in scope, score the *planned*
    surface against the dimensions below and write a predicted scorecard to `devex.md` (the
    estimate, e.g. "time-to-hello-world: ~3 min"). This is cheap and pre-build; it forces the
    ergonomics question before the contract sets.
-2. **Measure** — at `$rite-prove`, actually exercise the surface (run the getting-started flow,
+2. **Measure:** at `$rite-prove`, exercise the surface (run the getting-started flow,
    call the endpoint, invoke the CLI, trigger the error) and record the *measured* scorecard with
    evidence: real time-to-hello-world, the verbatim error text, the screenshot of the docs page.
-3. **Reconcile (the boomerang)** — at `$rite-seal`, compare predicted against measured. A material
-   gap — "the plan said 3 minutes, the getting-started flow actually took 8 and step 4 errored" —
+3. **Reconcile (the boomerang):** at `$rite-seal`, compare predicted against measured. A material
+   gap: "the plan said 3 minutes, the getting-started flow took 8 and step 4 errored":
    is a finding, not a rounding error. The estimate was wrong *or* the surface regressed; either
    way the developer using it pays, and the gap is exactly what a single end-state score would hide.
 
 The boomerang is what makes DX a measured axis rather than an opinion: the prediction is on
 record, so the measured reality can falsify it.
 
-## The scorecard — what to score
+## The scorecard: what to score
 
 One entity, one name: call the metric **time-to-hello-world (TTHW)** consistently, not "onboarding
 time" in one place and "setup time" in another. Score these dimensions; only the ones the diff
 touches:
 
-- **Discoverability** — can a developer find the entry point without reading the source? Is the
+- **Discoverability:** can a developer find the entry point without reading the source? Is the
   new surface named, exported, and documented where they'll look?
-- **Time-to-hello-world (TTHW)** — wall-clock from "I have the repo/package" to "I got one
+- **Time-to-hello-world (TTHW):** wall-clock from "I have the repo/package" to "I got one
   successful call/response/render". The headline number; measure it, don't estimate it at seal.
-- **Getting-started friction** — does the quickstart run *as written*, copy-pasted, on a clean
+- **Getting-started friction:** does the quickstart run *as written*, copy-pasted, on a clean
   checkout? Every undocumented prerequisite, wrong command, or missing step is friction.
-- **Error-message quality** — does a failure say *what* failed, *why*, and *how to recover*, with
-  the relevant ids (never secrets — see [`security.md`](security.md))? A bare stack trace, a
+- **Error-message quality:** does a failure say *what* failed, *why*, and *how to recover*, with
+  the relevant ids (never secrets: see [`security.md`](security.md))? A bare stack trace, a
   silent exit, or "an error occurred" is a defect on a developer-facing path.
-- **Ergonomics & consistency** — does the surface match the project's existing conventions
+- **Ergonomics & consistency:** does the surface match the project's existing conventions
   (naming, argument order, pagination, error shape)? An inconsistent new endpoint taxes everyone
   who learned the old ones. Sensible defaults; the common case is one call.
-- **Docs accuracy** — examples are copy-pasteable and correct, the signature in the docs matches
+- **Docs accuracy:** examples are copy-pasteable and correct, the signature in the docs matches
   the code, and changed behavior updated its docs in the same change ([`documentation.md`](documentation.md)).
 
 ## Measure, don't assert
@@ -79,8 +79,8 @@ touches:
 The same discipline as `performance.md` "measure first" and `testing.md` "see it fail first":
 
 - **Run it, don't read it.** A scorecard backed by "the code looks fine" is Source mode and says
-  so. The graded scorecard comes from actually invoking the surface — the getting-started flow on
-  a clean state, the real CLI `--help`, the real error path — and recording what happened.
+  so. The graded scorecard comes from invoking the surface (the getting-started flow on
+  a clean state, the real CLI `--help`, the real error path) and recording what happened.
 - **Quote the artifact.** Paste the verbatim error string, the exact failing command, the measured
   TTHW; for a docs/quickstart page, capture it through the browser-proof ladder
   ([`../skills/devrites-browser-proof/SKILL.md`](../../../devrites-browser-proof/SKILL.md)) and
@@ -88,32 +88,32 @@ The same discipline as `performance.md` "measure first" and `testing.md` "see it
 - **No measurement → no DX claim**, and usually no finding above Suggestion. "Feels confusing" is
   a hypothesis to test, not a verdict.
 
-## The gate — severity by who-pays
+## The gate: severity by who-pays
 
 DX findings carry the standard labels (Critical / Important / Suggestion / Nit / FYI), scaled to
 the cost the consumer bears, not to how polished it feels:
 
-- A **public/external contract that ships broken or wrong** — a documented command that errors, an
-  endpoint whose response contradicts its contract, a getting-started flow that can't complete — is
+- A **public/external contract that ships broken or wrong** (a documented command that errors, an
+  endpoint whose response contradicts its contract, a getting-started flow that can't complete) is
   **Important**, and **Critical** when it's a frozen public surface (the principles-gated public-API
   invariant, [`principles.md`](principles.md)) or an irreversible break.
 - A **measured DX regression** against the predicted scorecard with no recorded reason is a
-  finding the boomerang surfaces at seal — at least **Important** when it lands on a public surface.
-- An **unactionable error message** on a developer-facing failure path is **Important** — the
+  finding the boomerang surfaces at seal, at least **Important** when it lands on a public surface.
+- An **unactionable error message** on a developer-facing failure path is **Important**: the
   on-call test ([`observability.md`](observability.md)) applied to the consumer instead of the operator.
 - Inconsistent-but-working ergonomics, a thin doc, a missable default → **Suggestion**, unless the
   spec made it acceptance.
 
-## The artifact — `devex.md`
+## The artifact: `devex.md`
 
 When a developer-facing surface is in scope, the workspace carries `devex.md`: the **predicted**
 scorecard (from `$rite-vet`), the **measured** scorecard with evidence (from `$rite-prove`), and
 the **boomerang delta** (reconciled at `$rite-seal`). Absent surface → no `devex.md`, and the gate
-passes silently — never block a change for the *absence* of a DX surface, the same no-op discipline
+passes silently: never block a change for the *absence* of a DX surface, the same no-op discipline
 as the principles and spec-grammar gates.
 
 ## Scope discipline
 
 Review the developer-facing surface the change *touches*. A surface the diff didn't change is not
-this change's job; a project-wide DX audit (every endpoint, the whole CLI) is its own effort —
+this change's job; a project-wide DX audit (every endpoint, the whole CLI) is its own effort:
 record it as a follow-up, don't smuggle it into an unrelated change.

package/pack/generated/codex/skills/devrites-lib/reference/standards/development-workflow.md

@@ -4,7 +4,7 @@ Ship small, integrate often, keep the main branch releasable. DevRites runs this
 lifecycle atop that loop: spec → define → vet → build → prove → polish → review → seal → ship.
 
 ## Work in small batches
-- Break work into thin, independently shippable slices and integrate them frequently —
+- Break work into thin, independently shippable slices and integrate them frequently:
   ideally merging to the main branch at least once a day.
 - Small batches shrink merge pain, surface integration problems early, and get real
   reviews. Large batches hide defects and stall.
@@ -18,33 +18,33 @@ lifecycle atop that loop: spec → define → vet → build → prove → polish
   partial work can land without blocking releases or breaking the trunk.
 
 ## Review gate
-- Every change is reviewed before merge (see `code-review.md`). Keep reviews fast — slow
+- Every change is reviewed before merge (see `code-review.md`). Keep reviews fast: slow
   reviews push people back toward big, risky batches.
 - Set expectations on PR size and merge cadence: small, frequent, single-concern.
 
 ## Definition of done
-The **Definition of Done** is the project's *standing bar* — the floor every change clears,
+The **Definition of Done** is the project's *standing bar*: the floor every change clears,
 distinct from a slice's **acceptance criteria** (which change per slice and say what *this* work
 must do). Acceptance criteria answer "did we build the right thing"; the DoD answers "is it
-shippable at all". The bar does not move with deadline pressure — a Definition of Done that gets
+shippable at all". The bar does not move with deadline pressure: a Definition of Done that gets
 renegotiated each time is not one. Apply it in tiers so the cost matches the scope:
 
-- **Every slice** — Correctness + Quality: meets its acceptance criteria with **evidence**
-  (tests/build/runtime — see `testing.md`), behaviour verified at runtime not just compiled; tests
+- **Every slice:** Correctness + Quality: meets its acceptance criteria with **evidence**
+  (tests/build/runtime: see `testing.md`), behaviour verified at runtime not just compiled; tests
   and build green in CI; reviewed and **within scope, no unrelated refactor snuck in**; edge and
   error paths handled, not only the happy path.
-- **Every feature** — Integration + Documentation: works with the rest of the system, migrations/
+- **Every feature:** Integration + Documentation: works with the rest of the system, migrations/
   config/flags accounted for, backward compatibility considered for any public-interface change;
   docs/comments touched are updated (`documentation.md`) and describe the *current state in timeless
   language*, not the change history.
-- **Every release** — Ship-readiness: security reviewed for any untrusted input/auth/data
+- **Every release:** Ship-readiness: security reviewed for any untrusted input/auth/data
   (`security.md`), observability on new critical paths (`observability.md`), a **rollback for
   anything risky**, and a **human has reviewed and approved before merge**.
 
-Two invariants across all tiers: evidence post-dates the code it proves — edits made after
+Two invariants across all tiers: evidence post-dates the code it proves: edits made after
 `$rite-prove` (polish/review) require re-proof before seal, stale evidence is not proof; and
 "tests pass" is not a synonym for done. "Code written" is not done. "Proven and reviewed" is.
 
 ## Incremental delivery
 Deliver a working end-to-end path each slice, then expand. Avoid the "90% done, nothing
-proven" pile-up — one finished, verified slice beats five half-built ones.
+proven" pile-up: one finished, verified slice beats five half-built ones.

package/pack/generated/codex/skills/devrites-lib/reference/standards/documentation.md

@@ -1,6 +1,6 @@
 # Documentation
 
-Write the documentation that saves the next person time — no more, no less.
+Write the documentation that saves the next person time: no more, no less.
 
 ## Explain why, keep it current
 - Document **intent and decisions**, not a restatement of the code. The *why* is what
@@ -17,14 +17,14 @@ Write the documentation that saves the next person time — no more, no less.
   code; only the ADR records the options you weighed and *why each lost*. List them with the reason
   each was rejected, or the note answers nothing the source doesn't already show.
 - **An ADR has a lifecycle:** `PROPOSED → ACCEPTED → SUPERSEDED / DEPRECATED`. When a decision
-  changes, write a **new** ADR that references and supersedes the old one — never edit or delete the
+  changes, write a **new** ADR that references and supersedes the old one: never edit or delete the
   original, or you erase the record of why the project once chose differently.
 
 ## What to document
-- **Public surfaces**: APIs, module boundaries, and config — inputs, outputs, errors,
+- **Public surfaces**: APIs, module boundaries, and config: inputs, outputs, errors,
   and gotchas. Writing the contract down is the first test of the design: documenting a public
   interface surfaces its rough edges before the code sets around them.
-- **READMEs that actually run**: setup, the real commands to build/test/run, and how to
+- **READMEs that run**: setup, the real commands to build/test/run, and how to
   get a working environment. Keep examples copy-pasteable and correct.
 - **Non-obvious constraints**: invariants, ordering requirements, "do not call X before
   Y", and known limitations.

package/pack/generated/codex/skills/devrites-lib/reference/standards/edge-case-trace.md

@@ -6,7 +6,7 @@ Use this when a diff changes branching logic, boundaries, validation, deletion,
 
 1. **Scope the changed surface.** Name the changed function/API/state/config and the nearest observable caller.
 2. **Enumerate explicit paths.** Walk each `if`/`switch`/loop/error branch and boundary value the changed surface handles.
-3. **Enumerate fixed-set siblings.** If the change special-cases members of a known set — enum values, statuses, sentinels, flags, roles, modes — list the untouched siblings too. A handled `pending`/`failed` branch makes `success` an implicit branch to check.
+3. **Enumerate fixed-set siblings.** If the change special-cases members of a known set (enum values, statuses, sentinels, flags, roles, modes) list the untouched siblings too. A handled `pending`/`failed` branch makes `success` an implicit branch to check.
 4. **Check deletion contracts.** For removed or replaced code, name the behavior or contract it carried and where the diff re-establishes it. If it was intentionally retired, cite the spec/decision that retires it.
 5. **Report only reachable gaps.** A finding needs `file:line`, trigger condition, missing guard/handling, and concrete consequence. If the path is already handled, drop it silently.
 

package/pack/generated/codex/skills/devrites-lib/reference/standards/elicitation.md

@@ -1,13 +1,13 @@
-# Elicitation — a move-set for the thinking phases
+# Elicitation: a move-set for the thinking phases
 
-The thinking phases (`$rite-temper` on the spec, `$rite-vet` on the plan) default to one shape each
-— a pre-mortem, a plan review. That's a floor, not a ceiling. When a section needs deeper thought,
+The thinking phases (`$rite-temper` on the spec, `$rite-vet` on the plan) default to one shape each.
+A pre-mortem, a plan review. That's a floor, not a ceiling. When a section needs deeper thought,
 this is the menu you reach into: named reasoning techniques, each with the shape it produces, so
 "make this stronger" becomes a concrete move instead of a vibe.
 
-## How to use it (progressive — no ceremony by default)
+## How to use it (progressive: no ceremony by default)
 1. Look at the **one section** in front of you (a requirement, a risk, an estimate, a boundary).
-2. Read its **risk**, then pull the 3–5 techniques below whose *When to reach for it* matches.
+2. Read its **risk**, then pull the 3-5 techniques below whose *When to reach for it* matches.
 3. Present them as a short numbered menu; the human picks one (or `skip`).
 4. Run that technique on that section, apply the result, move on.
 
@@ -24,57 +24,57 @@ Selection is by the section's risk, not taste. Reach for the row that fits:
 
 ## The techniques
 
-Each entry is **name — when to reach for it — the shape it produces** (`→` reads "then").
+Each entry is **name (when to reach for it) the shape it produces** (`→` reads "then").
 
 ### Sharpening a claim
-- **Steelman-then-Attack** — a requirement or approach you're inclined to accept. Build the
+- **Steelman-then-Attack:** a requirement or approach you're inclined to accept. Build the
   *strongest* case for it → then attack that strongest form. Survives → keep; falls → revise.
-- **Devil's Advocate** — consensus formed too fast. One voice argues the opposite in good faith →
+- **Devil's Advocate:** consensus formed too fast. One voice argues the opposite in good faith →
   surface the objection the room skipped.
-- **Assumption Audit** — a plan resting on unstated beliefs. List every assumption the section
+- **Assumption Audit:** a plan resting on unstated beliefs. List every assumption the section
   makes → mark each *load-bearing / verified / unverified* → the unverified load-bearing ones are
   the work.
-- **Five Whys** — a stated requirement whose *reason* is fuzzy. Ask "why" five times down from the
+- **Five Whys:** a stated requirement whose *reason* is fuzzy. Ask "why" five times down from the
   ask → reach the root need (often narrower or different than the surface ask).
 
 ### Stress-testing a decision
-- **Pre-Mortem** — before committing an irreversible choice. Assume it's six months later and this
+- **Pre-Mortem:** before committing an irreversible choice. Assume it's six months later and this
   failed → write the failure story → each cause becomes a mitigation or a blocking question. (This
   is `$rite-temper`'s default; the others deepen it.)
-- **Red-Team vs Blue-Team** — a security, trust-boundary, or adversarial-input surface.
+- **Red-Team vs Blue-Team:** a security, trust-boundary, or adversarial-input surface.
   `defense → attack → hardening`: state the defense, attack it as a hostile party, harden the gap.
-- **Inversion** — "how do we make X good?" stalls. Ask instead "how would we *guarantee X fails*?"
+- **Inversion:** "how do we make X good?" stalls. Ask instead "how would we *guarantee X fails*?"
   → invert each failure into a requirement.
-- **Second-Order Effects** — a change that touches shared surface. For each first-order effect ask
+- **Second-Order Effects:** a change that touches shared surface. For each first-order effect ask
   "and then what?" twice → surface the downstream consequence the diff hides.
 
 ### Sizing and estimating
-- **Delphi** — an estimate one person is anchoring. Gather independent estimates *without* seeing
+- **Delphi:** an estimate one person is anchoring. Gather independent estimates *without* seeing
   each other → reveal → discuss the spread → re-estimate → converge. Kills anchoring.
-- **Reference-Class Forecast** — "this'll be quick." Find 3 past changes of the same *class* → use
+- **Reference-Class Forecast:** "this'll be quick." Find 3 past changes of the same *class* → use
   their actual cost as the base rate, not the inside view.
 
 ### Widening the option space
-- **Tournament (A vs B)** — two plausible designs. Put them head-to-head on the *decision hinge*
-  (the one axis that actually differs) → pick on that axis, not on a feature checklist.
-- **Analogy Mapping** — a novel problem. "What is this *like* that's already solved?" → borrow the
+- **Tournament (A vs B):** two plausible designs. Put them head-to-head on the *decision hinge*
+  (the one axis that differs) → pick on that axis, not on a feature checklist.
+- **Analogy Mapping:** a novel problem. "What is this *like* that's already solved?" → borrow the
   solved structure, note where the analogy breaks.
-- **Scope Extremes** — a spec of uncertain size. Describe the *MVP* (smallest thing that ships
+- **Scope Extremes:** a spec of uncertain size. Describe the *MVP* (smallest thing that ships
   value) and the *gold-plated* version → the right scope is usually named by the gap between them.
-- **YAGNI Pass** — a plan carrying "might need it later." For each speculative piece, demand a
+- **YAGNI Pass:** a plan carrying "might need it later." For each speculative piece, demand a
   *current* acceptance criterion → no criterion, cut it to a follow-up.
 
 ### Finding what's missing
-- **Edge-Case Hunt** — a happy-path-shaped spec. Walk empty / boundary / invalid / concurrent /
+- **Edge-Case Hunt:** a happy-path-shaped spec. Walk empty / boundary / invalid / concurrent /
   huge-or-weird input for each element → each uncovered case is a missing criterion.
-- **Chaos Scenarios** — a system with external dependencies. "What if the DB is down / the API
+- **Chaos Scenarios:** a system with external dependencies. "What if the DB is down / the API
   times out / the clock jumps / the input is hostile?" → each becomes a failure-mode requirement.
-- **Completeness Critic** — end of a section. Ask only "what's *missing* — a modality not covered, a
+- **Completeness Critic:** end of a section. Ask only "what's *missing*: a modality not covered, a
   claim not verified, a flow with no path?" → the answer is the next round of work.
 
 ## The one rule
-Run the technique on the **section in front of you**, not the whole document — a move applied to
+Run the technique on the **section in front of you**, not the whole document: a move applied to
 everything is a move applied to nothing. Record what it changed in the phase artifact (a new
 requirement, a mitigation, a blocking question), not just that you ran it.
 
-A project can append its own house techniques to this file — same three-column shape.
+A project can append its own house techniques to this file: same three-column shape.

package/pack/generated/codex/skills/devrites-lib/reference/standards/error-handling.md

@@ -9,21 +9,21 @@ recoverable.
   later.
 
 ## No silent catches
-- Never swallow an error to make a problem "go away" — that hides bugs and corrupts
+- Never swallow an error to make a problem "go away", that hides bugs and corrupts
   state silently.
-- Catch the **narrowest** error you can actually handle, not a blanket catch-all. A
+- Catch the **narrowest** error you can handle, not a blanket catch-all. A
   bare/broad catch masks unrelated failures.
 - If you catch, either recover meaningfully, or rethrow/wrap with added context. Don't
   log-and-continue past an error you didn't handle.
 
 ## Meaningful messages
-- Error messages state what failed, the relevant context (ids, inputs — not secrets),
+- Error messages state what failed, the relevant context (ids, inputs, not secrets),
   and ideally how to recover. Cryptic messages cost hours.
 - Distinguish *expected* failures (validation, not-found) from *unexpected* (bugs);
   handle the first as flow, surface the second.
 
 ## Fail closed (security-relevant paths)
-- On error in an auth/permission/transaction path, **deny and roll back** — never
+- On error in an auth/permission/transaction path, **deny and roll back**: never
   default to granting access or committing partial state.
 
 ## Logging

package/pack/generated/codex/skills/devrites-lib/reference/standards/git-workflow.md

@@ -22,17 +22,17 @@ Refs: #123
 
 ## Atomic commits
 - One logical change per commit; it should build and pass tests on its own.
-- Don't mix refactor + behavior change in one commit — split them so each is reviewable
+- Don't mix refactor + behavior change in one commit: split them so each is reviewable
   and revertible.
 
 ## Small, focused branches/PRs
 - One concern per branch. Short-lived; rebase/merge per the project's convention.
 - Keep PRs small (see `code-review.md`) so they get a real review.
 
-## Change summary — prove the scope
+## Change summary: prove the scope
 When you hand back a change, state what you deliberately left alone, not only what you touched.
-A **"Things I didn't touch (intentionally)"** line — the adjacent smells you noticed and declined
-to fix — proves the diff is feature-scoped ([`core.md`](core.md) rule 7) and matches
+A **"Things I didn't touch (intentionally)"** line (the adjacent smells you noticed and declined
+to fix) proves the diff is feature-scoped ([`core.md`](core.md) rule 7) and matches
 `touched-files.md`, rather than an unsolicited renovation the reviewer has to untangle from the
 real change. Noticed-but-not-fixed becomes an FYI follow-up, never a silent addition to this diff.
 
@@ -49,17 +49,17 @@ When git is mid-merge or mid-rebase, recover before other workflow work:
 
 ## Versioning & changelog
 - **The version is a promise.** Semver encodes what a consumer may rely on. A "patch" that
-  changes behaviour someone depended on is a major wearing a disguise — every observable behaviour
+  changes behaviour someone depended on is a major wearing a disguise: every observable behaviour
   is a contract (Hyrum's law, [`deprecation.md`](deprecation.md)). When unsure whether a change is
   breaking, assume it is; a surprise major is far cheaper than a broken consumer.
 - **The tag is the single source of truth** for the version. Derive it from the tag; never
-  hand-edit a version copied across `package.json`, a constant, and a header — three copies drift,
+  hand-edit a version copied across `package.json`, a constant, and a header: three copies drift,
   one tag can't.
-- **A changelog is not the git log.** Curate it by user impact — what a consumer must know to
-  upgrade — not by commit. Write the entry in the same change that earns it, while the impact is
+- **A changelog is not the git log.** Curate it by user impact (what a consumer must know to
+  upgrade) not by commit. Write the entry in the same change that earns it, while the impact is
   fresh; a changelog reconstructed later is a guess.
 
 ## Never commit
 - Secrets, credentials, tokens, or `.env` files. If one lands in history, rotate it and
-  scrub it — deleting the file in a later commit is not enough.
+  scrub it: deleting the file in a later commit is not enough.
 - Generated artifacts, dependencies, or large binaries that belong in ignore rules.

package/pack/generated/codex/skills/devrites-lib/reference/standards/hooks.md

@@ -2,7 +2,7 @@
 
 Automate the checks humans forget, at the cheapest stage that can catch the problem.
 The guiding constraint: **the hook nobody runs is worse than a slower hook that still
-catches things — so keep local hooks fast and scoped.**
+catches things, so keep local hooks fast and scoped.**
 
 ## Stage the work by cost (the 10-second rule)
 - **pre-commit** (must finish in well under ~10s): format, lint, and secret-scan the
@@ -19,7 +19,7 @@ catches things — so keep local hooks fast and scoped.**
 | pre-commit | formatter, fast linter, secret scan, changed-files checks | the full test suite |
 | commit-msg | commit-message lint | anything slow |
 | pre-push | affected unit/integration tests | end-to-end matrices |
-| CI | everything (suite, build, e2e, security) | — |
+| CI | everything (suite, build, e2e, security) |: |
 
 ## Keep hooks fast
 - Operate on **staged/changed files**, not the whole tree.
@@ -27,7 +27,7 @@ catches things — so keep local hooks fast and scoped.**
 - Prefer fast tools; a slow check belongs in CI, not the commit path.
 
 ## Secret scanning
-Scan for credentials/keys/tokens before they enter history — catching a secret
+Scan for credentials/keys/tokens before they enter history: catching a secret
 pre-commit is cheap; rotating a leaked one is not.
 
 ## Adoption & escape hatches

package/pack/generated/codex/skills/devrites-lib/reference/standards/observability.md

@@ -1,30 +1,30 @@
 # Observability
 
-Observability is proof the feature works in **production** — the evidence ladder extended
+Observability is proof the feature works in **production**: the evidence ladder extended
 past your machine. `$rite-prove` shows it works on localhost; observability is how you know
 it still works, and why it broke, once real traffic hits it. Un-instrumented code is a claim
 you can't verify after deploy.
 
-## Scope — when this applies
+## Scope: when this applies
 Only when the change has a runtime surface worth debugging in prod: a new endpoint/route, a
 background job, a queue consumer, an external integration, a user-facing flow, or a new error
-path. Skip it for pure-internal refactors, docs, config-only, or type-only changes — the same
+path. Skip it for pure-internal refactors, docs, config-only, or type-only changes: the same
 scope discipline as [`performance.md`](performance.md). Don't instrument a typo fix.
 
 ## The on-call test
 The litmus for "is this observable": **if this breaks at 3am, can you tell *what* broke and
-*why* from the signals alone — without shipping a new build just to add logging?** If the
+*why* from the signals alone, without shipping a new build just to add logging?** If the
 answer is no, it isn't done. Instrument the failure path you just wrote, not only the happy
 path.
 
-**Write the questions first.** Before instrumenting, name the 2–4 questions an on-call engineer
+**Write the questions first.** Before instrumenting, name the 2-4 questions an on-call engineer
 will ask ("which dependency is down?", "which tenant is affected?"); every signal you add
 answers one of them. A signal that maps to no question is noise you pay to store and never read.
 
 ## Structured logs
 - Log the events you'd need to reconstruct a failure: request boundaries, state transitions,
   external-call outcomes, validation rejections, and authz denials.
-- Structured (key/value or JSON), not string soup — a log you can't query is a log you won't
+- Structured (key/value or JSON), not string soup: a log you can't query is a log you won't
   read. Carry a correlation id (request / trace / job id) so one incident's lines join up.
 - **Never log secrets, tokens, or PII** ([`security.md`](security.md),
   [`error-handling.md`](error-handling.md)). Levels mean something: `error` is a page-worthy
@@ -33,34 +33,34 @@ answers one of them. A signal that maps to no question is noise you pay to store
 ## Metrics & SLIs
 - Cover the signals that page someone: request rate, error rate, latency/duration, and
   saturation of any bounded resource the change adds (a pool, a queue, a cache).
-- Emit a counter on the **failure** branch, not just success — an error you don't count is an
+- Emit a counter on the **failure** branch, not just success: an error you don't count is an
   error you can't alert on.
 - Name the one Service Level Indicator for the feature's critical path; pin a target (SLO)
   when the project tracks them.
 - **Cardinality is the metric failure mode.** A label's values come from a small, fixed set.
-  Never label a metric with `user_id`, `email`, `request_id`, a full URL, or raw error text —
+  Never label a metric with `user_id`, `email`, `request_id`, a full URL, or raw error text:
   unbounded label values explode the series count and the bill. Group by class (`5xx`, not
   `503`); put the high-cardinality id in a log line or a trace, where it belongs.
 - **Percentiles always, averages never.** Read latency as a histogram at p50 / p95 / p99. An
-  average hides the tail, and the tail is where the pain — and the SLO breach — lives.
+  average hides the tail, and the tail is where the pain (and the SLO breach) lives.
 
 ## Traces (across a boundary)
 When a request crosses a service, queue, or async boundary, propagate a trace/correlation id
 so the end-to-end path is reconstructable, and span the external call and the slow operation.
 A latency regression you can't attribute to a span is a guess.
 
-## Alerts — symptom, not cause
-Alert on user-visible symptoms (error-rate spike, SLO burn), not on every internal gauge — a
+## Alerts: symptom, not cause
+Alert on user-visible symptoms (error-rate spike, SLO burn), not on every internal gauge: a
 noisy alert gets muted, and a muted alert is no alert. Every alert names an owner and a first
 action, or it's noise.
 
 Two severities, and only two: **page** (a human must act now) and **ticket** (handle it within
-hours). A third tier is the noise everyone learns to mute — collapse it into one of the two.
+hours). A third tier is the noise everyone learns to mute: collapse it into one of the two.
 
 ## Verify the telemetry fires (evidence, not assumption)
-Instrumentation you added but never watched emit is unproven — the same standing as a test you
+Instrumentation you added but never watched emit is unproven: the same standing as a test you
 never saw fail ([`testing.md`](testing.md) "See it fail first"). Trigger the path, confirm the
-log line / metric / span actually appears, and record the observation in `evidence.md`. "I
+log line / metric / span appears, and record the observation in `evidence.md`. "I
 added logging" with no observed emission is not done.
 
 ## Confirm-before-remove
@@ -70,4 +70,4 @@ beats no-usage-assumed.
 
 ## Scope discipline
 Instrument what the change touches. Retrofitting observability across a whole service is its
-own effort — record it as a follow-up, don't smuggle it into an unrelated change.
+own effort: record it as a follow-up, don't smuggle it into an unrelated change.

package/pack/generated/codex/skills/devrites-lib/reference/standards/patterns.md

@@ -1,23 +1,23 @@
 # Patterns & architecture
 
-Patterns are tools for **loose coupling and clarity** — not a goal. Use one only when it
+Patterns are tools for **loose coupling and clarity**, not a goal. Use one only when it
 makes the design simpler to reason about, not to show it's there.
 
 ## Principles
-- **SOLID, applied with judgment** — single responsibility, open/closed, Liskov,
+- **SOLID, applied with judgment:** single responsibility, open/closed, Liskov,
   interface segregation, dependency inversion. They're guidance toward low coupling and
   high cohesion, not boxes to tick.
-- **Composition over inheritance** — prefer assembling behavior from small pieces over
+- **Composition over inheritance:** prefer assembling behavior from small pieces over
   deep class hierarchies; inheritance couples tightly and resists change.
-- **Depend on abstractions at real seams** — inject dependencies where you genuinely
+- **Depend on abstractions at real seams:** inject dependencies where you genuinely
   need to swap or test them; don't wrap everything in an interface "just in case".
-- **Separation of concerns** — keep I/O, business logic, and presentation in distinct
+- **Separation of concerns:** keep I/O, business logic, and presentation in distinct
   layers so each can change and be tested on its own.
 
 ## Choose the pattern after you understand the problem
 - Identify the actual architectural challenge first; pick the pattern that fits it.
   A pattern applied to the wrong problem adds indirection and cost.
-- Start with the **simplest structure that works** — a modular monolith beats premature
+- Start with the **simplest structure that works**: a modular monolith beats premature
   microservices for a small team. Scale the architecture when load or team size demands
   it, not before.
 
@@ -27,13 +27,13 @@ makes the design simpler to reason about, not to show it's there.
 - Don't force a pattern everywhere; not every problem needs one.
 - Watch the cost: misused patterns add memory/indirection/overhead and obscure intent.
 - A refactor must **reduce** complexity, not just **relocate** it. Count the concepts a
-  reader must hold; if a "cleaner" version leaves that count unchanged it isn't cleaner —
+  reader must hold; if a "cleaner" version leaves that count unchanged it isn't cleaner:
   prefer the restructuring that makes whole branches/modes/layers disappear.
 
 ## Anti-patterns to name and avoid
 - God object / god function doing everything; tight coupling across layers.
 - Hidden global state and singletons used as a back door.
-- Copy-paste duplication instead of a shared abstraction (and its opposite — a clever
+- Copy-paste duplication instead of a shared abstraction (and its opposite: a clever
   abstraction over two things that aren't really the same).
 - Speculative generality: config, hooks, and extension points with no current user.
 

package/pack/generated/codex/skills/devrites-lib/reference/standards/performance.md

@@ -3,7 +3,7 @@
 Measure first. An optimization without a measurement is a guess that adds complexity.
 
 ## Measure before you optimize
-- Establish a number: a timing, a query count, a payload/bundle size, a memory figure —
+- Establish a number: a timing, a query count, a payload/bundle size, a memory figure:
   against a budget or a baseline.
 - No measurement → no performance claim, and usually no change. "Feels slow" is a
   hypothesis to test, not a reason to refactor.
@@ -17,13 +17,13 @@ Measure first. An optimization without a measurement is a guess that adds comple
 
 ## Optimize responsibly
 - Fix the **measured** bottleneck, then **re-measure** to prove the win (before/after).
-  An optimization that doesn't move the number is just added complexity — revert it.
+  An optimization that doesn't move the number is just added complexity: revert it.
 - Don't trade correctness or readability for a micro-win that doesn't matter.
 - Prefer a better algorithm or query over micro-tuning; the big wins are structural.
 
-## Frontend — Core Web Vitals
+## Frontend: Core Web Vitals
 For UI work, measure-first means LCP / INP / CLS judged against real numbers, each labeled
-by source (`Field (CrUX)`, `Lab (Lighthouse)`, `Trace (DevTools)`) — field and lab are not
+by source (`Field (CrUX)`, `Lab (Lighthouse)`, `Trace (DevTools)`): field and lab are not
 interchangeable, and static source cannot measure a CWV. The reviewer captures these via the
 browser-proof ladder when a budget exists, then judges them in Measured mode (a
 source-labeled scorecard); with no artifact it runs in Source mode and names the command.
@@ -32,5 +32,5 @@ Baseline checks + measurement commands:
 
 ## Scope
 Optimize what the change touches or what a measurement flags. Project-wide performance
-work is its own effort — record it as a follow-up, don't smuggle it into an unrelated
+work is its own effort: record it as a follow-up, don't smuggle it into an unrelated
 change.