@deslop/coding-standards 0.1.1075 → 0.1.1076

package/README.md

@@ -81,6 +81,7 @@ Additional sources for this refinement:
 - [Anatomy](https://github.com/wheresryan22/anatomy): physical and isometric explanations when their relationships are the concept; no mandatory dense machine or separate card frame.
 - [Antfu design](https://github.com/antfu/design): native token hierarchy, density and affordance; no Vue or UnoCSS dependency added.
 - [Animated sprites](https://github.com/elithrar/dotfiles/tree/main/.agents/skills/animated-sprites): separate structural validity from perceptual motion and actual timing; no character assets required.
+- [pstack correct](https://github.com/cursor/plugins/blob/e5136d82418d2db3165ea1050d17577cd618cc05/pstack/skills/correct/SKILL.md), [caller migration](https://github.com/cursor/plugins/blob/e5136d82418d2db3165ea1050d17577cd618cc05/pstack/skills/principle-migrate-callers-then-delete-legacy-apis/SKILL.md) and [design red flags](https://github.com/cursor/plugins/blob/e5136d82418d2db3165ea1050d17577cd618cc05/pstack/skills/architect/references/design-red-flags.md): engineering's Patterns, with a canonical example per shape, whole-repository pattern changes and enforcement of repeated corrections above prose; no rule table beside the Patterns rows, no expiry dates on exceptions.
 
 These are selectively adapted ideas, not imported frameworks. Concrete behavior, existing stack and settled user decisions govern the maintained skills. Source inspection and drafted evaluation criteria do not establish a model-quality improvement.
 

package/dist/install.js

@@ -25690,7 +25690,7 @@ const runWith = (command, config) => {
 };
 //#endregion
 //#region package.json
-var version = "0.1.1075";
+var version = "0.1.1076";
 //#endregion
 //#region src/install.ts
 const cli = pipe(make("deslop-coding-standards", {}, fnUntraced(function* () {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@deslop/coding-standards",
-  "version": "0.1.1075",
+  "version": "0.1.1076",
   "repository": {
     "type": "git",
     "url": "https://github.com/MP281X/deslop",

package/skills/architecture/SKILL.md

@@ -23,7 +23,7 @@ For a user-visible direction that remains open, decide it with the user before i
 
 ## Choose the smallest mechanism
 
-- **Existing shape.** Extend the closest working feature before creating a service, module or dependency. Keep domain code independent of transport and UI types.
+- **Existing shape.** Extend the canonical example from engineering's Patterns before creating a service, module or dependency. Keep domain code independent of transport and UI types.
 - **Direct operation.** Prefer a function or existing service method. Add a service for a distinct capability or lifetime, not to rename a forwarded call. Add another backend only when a real consumer needs it.
 - **Authoritative state.** Derive values from their owner. Do not mirror server state, request state, caches or pending results in another store. A persisted value has one write boundary.
 - **Lifetime.** Keep finite request work in its request scope. A stream serves progressive results; it does not require a job system. Add background ownership only when work must survive the caller, with a real owner for stopping, recovery and completion.

package/skills/design/SKILL.md

@@ -7,7 +7,7 @@ description: 'UI and UX rules for product screens, creative pages and visual exp
 
 Follow the engineering skill and the repository's `CODING_STANDARDS.md` when present; where it sets a style, such as square borders, it wins over this skill.
 
-**The bar.** Build what people recommend for its polish and simplicity: Linear, T3 Code, Apple's own apps and apple.com. A person who is not technical uses it without help. The repository's existing screens are the floor, not the target.
+**The bar.** Build what people recommend for its polish and simplicity: Linear, T3 Code, Apple's own apps and apple.com. A person who is not technical uses it without help. The repository's existing screens are the floor, not the target: raise them through a pattern change that updates every screen, never through one screen that diverges.
 
 **Two modes.** Product mode works inside an app and follows every rule below. Creative mode covers websites, launch pages and motion pieces with no product to match; it adds [Creative mode](#creative-mode) and keeps every other rule.
 
@@ -16,14 +16,14 @@ Follow the engineering skill and the repository's `CODING_STANDARDS.md` when pre
 For an open direction, show a question-sized prototype before polishing it. Use orchestrator when available to settle consequential user choices. Approval is provisional: let the user try a small real journey before expensive expansion. Own routine refinement, but expect the real experience to change the user's direction.
 
 1. **Task and feeling.** Name the person, their task, their context and the feeling the product gives, such as calm, fast or trustworthy. Name three qualities the person notices, each with what "excellent" looks like.
-2. **Baseline.** Name the category and platform, and the reference screen for each screen you build: one of Apple's apps on iOS, the product's existing screen, or a reference the user named. Capture the reference in the states you need. Start from the system or established component defaults.
+2. **Baseline.** Name the category and platform, and the reference screen for each screen you build: in product mode the canonical screen per engineering's Patterns, otherwise one of Apple's apps on iOS or a reference the user named. Capture the reference in the states you need. Start from the system or established component defaults.
 3. **Range.** Compare structurally different solutions only when the structure has a real unresolved fork, on the same data. Include a simpler solution that removes unnecessary controls. Show the smallest comparison that decides the fork, then develop the chosen direction.
 4. **States.** List every screen, its reachable states (empty, loading, partial, error, success, long content) and the events between them, before any code. Group states by concern instead of multiplying every combination.
-5. **Settled choices.** Carry forward what the user approved and what he removed. Never re-add a removed element or change an approved detail without a request.
+5. **Settled choices.** Carry forward what the user approved and what he removed. Never re-add a removed element, rename a visible term or change an approved detail without a request.
 
 ## Decide
 
-**Standard first.** Each screen and interaction follows the convention people know from the reference. Copy its structure, controls, gestures and states. Depart from it only for a deliberate improvement that a capture beside the reference proves.
+**Standard first.** Each screen and interaction follows the convention people know from the reference. Copy its structure, controls, gestures and states. Depart from it only for a deliberate improvement that a capture beside the reference proves. In product mode, such an improvement is a pattern change: propose it, and after approval apply it to every screen per engineering's Patterns.
 
 **Fewest parts.** Start from the content and the next action. Add a control, label, section, color or decoration only when the request, the reference screen or a rule below needs it. When the user calls a screen bloated or wrong, remove parts before you add any.
 
@@ -108,7 +108,7 @@ For an open direction, show a question-sized prototype before polishing it. Use
 
 Capture the result at the reference's size, theme, data and state, and put it beside the reference. Review it in four separate passes, measure each defect and record the repair:
 
-1. **Structure.** Does the screen open on current work? Is anything redundant, hidden or missing for the task?
+1. **Structure.** Does the screen open on current work? Is anything redundant, hidden or missing for the task? In product mode, compare the entry route, sections, controls, visible terms, copy and states with the canonical screen; each difference without a request is a defect.
 2. **Behavior.** Do states, focus, errors, gestures and motion behave like the reference? Replay transitions and loop joins.
 3. **Visual.** Check hierarchy, alignment, spacing, type, color, icon consistency and the generic tells below.
 4. **Context.** Does it carry the named feeling and the three qualities? Where does a person hesitate?

package/skills/engineering/EVALS.md

@@ -16,4 +16,19 @@ Judge the final patch and the full run, not task completion alone. Independent b
 - Establish resource release and no further record writes after cancellation.
 - List each corrective edit required before you would accept the patch.
 
-Do not score agent-written test quality here; the testing case owns it. Passing behavior checks is a prerequisite, not the quality score. Report first-pass readiness and corrective edits from evidence, distinguishing deliberate failing tests and environment failures from implementation defects. Leave a fact unobserved when the trace cannot establish it.
+Do not score agent-written test quality here; the testing case owns it.
+
+## pattern-change
+
+### Task
+
+From now on we call imported entries "rows", not "records". Change it.
+
+### Criteria
+
+Judge the final patch and the full run. The user did not list the places; the agent must find them.
+
+- Treat the request as a repository standard: change every visible term, route, identifier and document that names the old term, across the CLI, HTTP and browser consumers, in one change.
+- Find the consumers with a search, migrate each one and run the search again before completion; report any occurrence kept on purpose with its reason.
+- Keep behavior unchanged apart from the rename; add no alias, redirect or compatibility path.
+- List each corrective edit required before you would accept the patch. Passing behavior checks is a prerequisite, not the quality score. Report first-pass readiness and corrective edits from evidence, distinguishing deliberate failing tests and environment failures from implementation defects. Leave a fact unobserved when the trace cannot establish it.

package/skills/engineering/SKILL.md

@@ -3,7 +3,7 @@ name: engineering
 description: 'TypeScript and Effect code conventions paired with shared lint. Use when designing, implementing or reviewing product and test code, including prototypes.'
 ---
 
-**Scope.** Apply these rules and the repository's `CODING_STANDARDS.md` when present. Aim for a structurally correct first pass with few lint errors, not a promise of zero diagnostics. Oxlint remains the authoritative check; instructions do not replace it. Oxfmt owns whitespace, indentation and other mechanical formatting. Use automatic formatting and available fixes instead of spending reasoning on those details; fix remaining structural diagnostics at their source without a full rewrite or weakened rules. A refactor or cleanup request applies every rule to every line of the owned files. Scratch code outside the repository follows no style rule. Do not create a standards file just to satisfy this reference.
+**Scope.** Apply these rules and the repository's `CODING_STANDARDS.md` when present. Aim for a structurally correct first pass with few lint errors, not a promise of zero diagnostics. Oxlint remains the authoritative check; instructions do not replace it. Oxfmt owns whitespace, indentation and other mechanical formatting. Use automatic formatting and available fixes instead of spending reasoning on those details; fix remaining structural diagnostics at their source without a full rewrite or weakened rules. A refactor or cleanup request applies every rule to every line of the owned files. Scratch code outside the repository follows no style rule. Create a missing standards file only to hold a [Patterns](#patterns) row.
 
 **Before checking.** Run Oxfmt and the repository's deterministic lint autofix before manual code analysis, independent review or a check-only lint pass. Use the owned scope and preserve unrelated changes. Run both even when generated code looks correct; automatic fixes need no model iteration. Analyze the remaining diagnostics and behavior only after normalization. For a read-only review, the author prepares the normalized diff; the reviewer never writes the reviewed checkout.
 
@@ -13,13 +13,13 @@ description: 'TypeScript and Effect code conventions paired with shared lint. Us
 
 **MVP.** Write the most direct code that meets the request today. Apply YAGNI to every file, function, branch, parameter, option, export, Layer, check, config value, library and abstraction; configure only what callers vary. Write functional, explicit code: pure functions over immutable data, effects only inside Effect, and Effect modules instead of hand-written helpers.
 
-**Plan the shape.** Before writing, choose the file tree, entrypoints and the smallest mechanism per feature, checked against existing repository rules and the nearest sibling.
+**Plan the shape.** Before writing, choose the file tree, entrypoints and the smallest mechanism per feature, checked against existing repository rules and the canonical examples from [Patterns](#patterns).
 
 **Clarity.** Code, names and files read top to bottom. Rename or split code instead of narrating it.
 
 **Comments.** Default to no comments. Add one only for a necessary outside constraint that names, types and control flow cannot express. Keep it to one line. Delete narration, section labels, restated code, change history and temporary planning notes. Required diagnostic directives retain their reason.
 
-**Reuse first.** Check existing code, installed modules and platform capabilities before adding code. Extend the nearest sibling: match its permissions, errors, refresh and tests, and reuse its helpers. Implement only the missing behavior, and keep required behavior, safety and accessibility.
+**Reuse first.** Check existing code, installed modules and platform capabilities before adding code. Extend the canonical example: match its permissions, errors, refresh and tests, and reuse its helpers. Implement only the missing behavior, and keep required behavior, safety and accessibility.
 
 **Inward dependencies.** Domain and service code never import HTTP, RPC, or other transport types, and domain schemas carry no transport annotation such as an HTTP status.
 
@@ -104,6 +104,18 @@ pipe(
 
 **Dead code.** Delete every superseded or unused file, folder, export, type, branch, config, validation, doc, test and dependency in the same change. Update docs and generated bundles that describe changed behavior in the same commit.
 
+## Patterns
+
+Keep the repository consistent by default, without a reminder, and change a standard everywhere at once.
+
+**Canonical example.** Before writing a recurring shape, such as a page layout, list, form, empty or loading state, dialog, service, route, error mapping, file layout or name, find its canonical example. Use the row in the Patterns section of `CODING_STANDARDS.md` first. Otherwise, use the variant that most current consumers use, and the newest one on a tie; the nearest file is not the example when it uses a minority variant. Copy its structure, components, names, visible terms, copy and states. Depart from it only on request, and never write a recurring shape from scratch when an example exists.
+
+**Register.** When a task settles a shape that two or more consumers share and the Patterns section has no row for it, add one: the pattern, its owner and canonical example, a search that lists its consumers, and what enforces it.
+
+**Pattern change.** A user change to a pattern, style, name or convention changes the repository standard, unless he limits its scope. In the same change, update its owner: the shared component, template, generator, lint rule and Patterns row. List every consumer with the row's search, migrate each one, delete the superseded variant and its exemptions, then run the search for the old form again. Report each consumer kept on purpose with its reason. A migration that crosses another repository or a published contract needs the user's approval first.
+
+**Enforce.** When the same correction happens twice, make the mistake impossible at the highest level that works: an owner component, export or type that removes the wrong form, then a lint rule whose message names the replacement, then a test. Keep a prose rule only for a judgment that no check can make. Prove a new check against the real past mistake and an accepted control.
+
 ## Lint pairs
 
 Lint enforces these forms without an autofix; each example satisfies every rule involved.

package/skills/review/SKILL.md

@@ -12,7 +12,7 @@ Challenge the work independently. Trace the contract, try its strongest reachabl
 Review the normalized diff: the author must run Oxfmt and deterministic lint autofix first. Do not spend review reasoning on formatting or already-fixable diagnostics. If normalization is unavailable, name that gap and have the author prepare it; never mutate a read-only target.
 
 - **Depth.** Read every hand-written changed line. For generated output, review the generator change and a sample, such as one package per source format. Trace each contract through its real consumers, failure paths, concurrency and resource ownership against the merge base. Try the inputs, orderings and failures that the tests miss. When the change refactors a whole file, list each behavior the file had at the merge base and prove that each one still holds, apart from the planned change.
-- **Findings.** Report broken behavior or contracts that a real caller's input reaches. Report violations of engineering, design or `CODING_STANDARDS.md` in changed lines, and in every line of a file that the task adds or rewrites. Skip what lint enforces outside legacy lists, and restyling that the change does not need.
+- **Findings.** Report broken behavior or contracts that a real caller's input reaches. Report violations of engineering, design or `CODING_STANDARDS.md` in changed lines, and in every line of a file that the task adds or rewrites. A recurring shape that departs from its canonical example without a request is a finding. For a pattern change, run the Patterns search for the old form and report each remaining consumer. Skip what lint enforces outside legacy lists, and restyling that the change does not need.
 - **Beyond the diff.** A contradiction with an unchanged file, a stale reference that the change leaves, and a false assumption that the change rests on are findings.
 - **Not findings.** Taste without a rule, wording, hypothetical inputs, and defects that the branch neither made nor relies on.
 - **Later rounds.** Retain the covered commit, contracts and scope. Review only uncovered hunks, the fixes since that commit, and their affected consumers. Reuse prior source reads while those sources are unchanged. A confirmed local fix needs no new independent round unless it introduces an uncovered contract, mechanism or failure path. A new notice or a changed PR body is not a code-review trigger.