@deslop/coding-standards 0.1.1077 → 0.1.1081

package/package.json

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

package/skills/architecture/EVALS.md

@@ -15,7 +15,7 @@ Judge the mechanism and caller obligations, not the number of modules or diagram
 - Reject an unnecessary job registry, detached writer, mirrored progress store and generic importer factory.
 - Give completion one observable meaning: the emitted record is durable.
 - Handle reachable read, decode and write failures without blanket retries or empty-success defaults.
-- Use a disposable experiment for an uncertain technical contract; ask only about an unresolved user outcome.
+- Use a disposable experiment for an uncertain technical contract; decide an unresolved user outcome from exploration and show it beside the strongest alternative; ask no question.
 - Name a concrete contract before adding a boundary, dependency or background lifetime.
 
 Grade simplicity and preserved behavior separately. A written design does not prove its implementation. Keep integrated planning and steering evaluations separate from this selected-skill case.

package/skills/architecture/SKILL.md

@@ -19,23 +19,21 @@ Before code, settle these facts in the current plan, without creating another do
 - The boundary where untrusted input becomes trusted data.
 - What remains durable after interruption, and how the caller knows.
 
-For a user-visible direction that remains open, decide it with the user before implementation; use orchestrator when available. File layout, module boundaries, public interfaces and names are the user's taste: when the Patterns and Taste sections of `CODING_STANDARDS.md` do not settle them, show the shape before code, per orchestrator's Taste gate when available. Settle technical mechanisms with source, a disposable inline probe or a small executable prototype. Do not ask the user to choose between implementation details that evidence can rank.
+Settle technical mechanisms with source or a probe per testing's Throwaway. File layout, module boundaries, public interfaces and names follow engineering's Taste.
 
 ## Choose the smallest mechanism
 
-- **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.
+- **Existing shape.** Extend the canonical example from engineering's Patterns before creating a service, module or dependency.
 - **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.
-- **Failure.** Handle failures the caller can reach. Validate at the boundary; retain domain identity, causes and completed work. Never turn failure into empty success or add blanket retries, fallbacks and catch-all defaults.
+- **Failure.** Handle failures the caller can reach, and keep domain identity, causes and completed work through them. Never turn a failure into empty success.
 - **Retries.** For a contract that permits retry after an unknown write outcome, keep the request identity stable for one intent. Add no retry policy or idempotency machinery to operations that do not need that contract.
-- **Boundaries.** Split code when dependencies, invariants or lifetimes differ. Prefer a substantive module to a chain of forwarding files. A small component or helper with one consumer stays beside that consumer.
+- **Boundaries.** Split code when dependencies, invariants or lifetimes differ. Prefer a substantive module to a chain of forwarding files.
 - **Variations.** Use explicit variants for genuinely different behaviors. Do not add boolean combinations, a plugin registry, a generic configuration object or a universal factory for hypothetical callers.
 
-Compare a new mechanism with the direct existing-module version. Count new state owners, boundaries, dependencies and failure paths, not just lines. Keep the simpler version unless a concrete contract rules it out. Prove that contract with a question-sized experiment; use a council only for a consequential unresolved tradeoff.
+Compare a new mechanism with the direct existing-module version. Count new state owners, boundaries, dependencies and failure paths, not just lines. Keep the simpler version unless a concrete contract rules it out. Prove that contract with a question-sized experiment.
 
 ## Challenge the design
 
-Try the strongest reachable counterexample: an interrupted write, repeated intent, stale response, overlapping caller or dependency failure. Check which owner preserves the invariant. Use testing to select evidence, not to turn every doubt into a permanent test.
-
-Remove each mechanism whose deletion preserves the required outcomes, existing reachable contracts, security, accessibility and useful regression protection. Do not defend an abstraction because it is already implemented. State what breaks without it; if nothing breaks, remove it.
+Try the strongest reachable counterexample: an interrupted write, repeated intent, stale response, overlapping caller or dependency failure. Check which owner preserves the invariant. Use testing to select evidence, not to turn every doubt into a permanent test. Do not defend an abstraction because it is already implemented: state what breaks without it, and remove it when nothing does.

package/skills/design/EVALS.md

@@ -14,7 +14,7 @@ Judge the browser experience, not the amount of UI produced.
 - Make idle, active, cancelled, completed and empty states understandable.
 - Keep completed records visible when the import stops; distinguish stop from undo.
 - Establish readable light and dark views at 390-point width, touch targets and keyboard access.
-- Settle the representative journey with the user before backend changes; expand only its approved direction.
+- Show the representative journey early in the real host and start the backend change at once; revise only the part the user's report steers.
 - Remove redundant controls and status text; use interaction to explore a real consequence, not to navigate an explanation.
 
 Inspect every visible state and transition. Grade hierarchy, behavior and readability independently of engineering and proof-capture quality. The user judges the final variants.
@@ -23,7 +23,7 @@ Inspect every visible state and transition. Grade hierarchy, behavior and readab
 
 ### Task
 
-Give me a quick overview of these changes: Review moved into coding-standards; Architecture was added; open choices need a prototype and approval; routine fixes do not; proof uses inline probes before permanent tests. These instruction changes are local, not installed. There are no UI captures, measurements or interactive choices to show.
+Give me a quick overview of these changes: Review moved into coding-standards; Architecture was added; open choices get an inline prototype beside the production code, with no approval wait; routine fixes need no prototype; proof uses inline probes before permanent tests. These instruction changes are local, not installed. There are no UI captures, measurements or interactive choices to show.
 
 ### Criteria
 

package/skills/design/SKILL.md

@@ -13,8 +13,6 @@ Follow the engineering skill and the repository's `CODING_STANDARDS.md` when pre
 
 ## Before the first draft
 
-For a screen that the recorded taste does not settle, agree on a realistic mock with the user before product code. Use orchestrator's Taste gate when available. 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: 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.** When the reference screen and the Taste section of `CODING_STANDARDS.md` do not settle the structure, compare 2–3 structurally different solutions on the same data. Include a simpler solution that removes unnecessary controls. Develop only the chosen direction.
@@ -23,7 +21,7 @@ For a screen that the recorded taste does not settle, agree on a realistic mock
 
 ## 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. In product mode, such an improvement is a pattern change: propose it, and after approval apply it to every screen per engineering's Patterns.
+**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, make such an improvement only when the request covers it, as a pattern change 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.
 
@@ -98,9 +96,9 @@ For a screen that the recorded taste does not settle, agree on a realistic mock
 
 ## Prototype and tune
 
-**Mocks.** Start the mock from the real screen: copy its rendered markup, theme tokens and fonts from the running app or its source, then change only what the decision needs. Keep its components, copy, spacing, realistic data and main states. For a native app, imitate the platform's system look; the mock settles structure, flow and the rough look. Add interaction only when manipulating the subject exposes a consequential difference; never add tabs or a state dashboard merely to navigate the explanation. Revise the mock until the user accepts the direction, then expand states and polish in code.
+**Mocks.** Start the mock from the real screen: copy its rendered markup, theme tokens and fonts from the running app or its source, then change only what the decision needs. Keep its components, copy, spacing, realistic data and main states. For a native app, imitate the platform's system look; the mock settles structure, flow and the rough look. Add interaction only when manipulating the subject exposes a consequential difference; never add tabs or a state dashboard merely to navigate the explanation.
 
-**Real host.** After the mock, build one complete representative journey with realistic data in the real host: the browser preview for the web, the simulator for a native app. Settle the final native appearance there. Let the user try it before broader implementation and polish. Complete specified fixes and approved-pattern work with focused proof, without a user checkpoint. Carry unaffected choices forward when feedback changes the journey; revise the affected design instead of defending the approved mock.
+**Real host.** The real host is the browser preview for the web and the simulator for a native app; settle the final native appearance there, and revise the affected design instead of defending the earlier mock.
 
 **Tune.** Settle values yourself. For values you cannot settle by reasoning, such as spacing, timing, springs or blur, capture candidates side by side, including both extremes, and judge them against the reference. Write the chosen values into the source and recapture.
 
@@ -113,7 +111,7 @@ Capture the result at the reference's size, theme, data and state, and put it be
 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?
 
-Repair in this order: grouping, hierarchy, alignment, copy, then states. Recapture after each batch, and stress long names, Unicode, 0, 1 and many records, the narrow phone and dark mode. Misalignment and inconsistent controls stay defects when types and tests pass.
+Repair in this order: grouping, hierarchy, alignment, copy, then states. Recapture after each batch, and stress long names, Unicode, 0, 1 and many records, the narrow phone and dark mode. Misalignment and inconsistent controls stay defects when types and tests pass. Show the result with captures per delivery's captures.
 
 | Generic tell                                    | Check                                                 |
 | ----------------------------------------------- | ----------------------------------------------------- |
@@ -124,8 +122,6 @@ Repair in this order: grouping, hierarchy, alignment, copy, then states. Recaptu
 | Generic copy such as "seamless" or "Learn more" | Each label names its capability or the outcome        |
 | Content that waits for an entrance animation    | The first frame is readable and actionable            |
 
-**Show the design.** Use screenshots for layout and short videos for behavior. Keep text readable on a phone, match the app's visual style and show the input, action and outcome without unrelated decoration. Evidence must show the real application.
-
 ## Creative mode
 
 Ground the page in its subject: name the audience and the page's one job, and take the visual language from the subject's world. Open with the most characteristic thing in its best form, such as a live demo, an image or a headline, and give the product one memorable signature. Interaction, navigation and reading stay conventional; novelty lives in composition, imagery and one choreographed moment. Concept before code: compare three compositions that differ in structure, not palette, and build the winner whole. Avoid defaults that read as generated: a cream canvas with a serif and a clay accent, identical rounded cards with soft shadows, all-caps eyebrows, and the hero, feature table, logo row and email form skeleton.
@@ -156,7 +152,7 @@ When none fits, choose the form that matches the data's shape; draw a list as a
 - **Labels.** Put names, values and units on the data, with one scale per comparison. Labels and captions stay under twelve words, and a visual holds no paragraphs.
 - **Real content.** Use actual names, operations and relationships. Keep a proposal distinct from an applied change, and a simulated explanation distinct from application evidence. A physical model is useful only when its operation explains the concept without another metaphor to decode.
 - **Interaction.** Keep the message understandable without a click. Add a control only to explore a real alternative or change an assumption. A predetermined change uses an automatic sequence, not a required click. On a phone, keep essential comparisons visible; do not hide the answer in tabs or menus.
-- **Motion.** Animate the subject from its real source to its destination. Keep identity, scale, alignment and unchanged context stable. Use transform and opacity, not per-frame layout. Make transitions brief and uninterrupted; pause only to let the reader see a state. If a demonstration needs replay, make its reset distinct from an undo. Do not use an invisible one-shot movement as the only explanation.
+- **Motion.** Animate the subject from its real source to its destination. Keep identity, scale, alignment and unchanged context stable. Use transform and opacity, not per-frame layout. Make transitions 180–350 ms and uninterrupted, with no decorative pulses; pause only to let the reader see a state. Replay a demonstration only when one pass is easy to miss, and make its reset distinct from an undo. Do not use an invisible one-shot movement as the only explanation.
 - **Host.** Match the enclosing UI's typography, density, controls, surfaces and semantic tokens, not only its colors. Keep the outer background transparent and remove unnecessary card wrappers. Prefer native CSS for simple automatic diagrams; use relative geometry instead of JavaScript sizing when it gives the same result.
 - **Proof.** Inspect the artifact in its actual host, including an intermediate frame and the final state. A valid file, a correct model or a headless screenshot alone does not prove readable, smooth, correctly triggered motion. Compare before and after at the same scale and actual playback speed. Fix a repeated failure in its representation or source, not with more prompt prohibitions.
 - **Check.** Use the host's theme variables, check light, dark and a 390-point width, and fix clipping, overlap and contrast before you show it. At that width the page stays under about 400 points tall.