@ryuenn3123/agentic-senior-core 3.0.48 → 3.0.50
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.agent-context/prompts/bootstrap-design.md +9 -10
- package/.agent-context/rules/api-docs.md +2 -0
- package/.agent-context/rules/architecture.md +2 -0
- package/.agent-context/rules/database-design.md +2 -0
- package/.agent-context/rules/error-handling.md +2 -0
- package/.agent-context/rules/frontend-architecture.md +11 -13
- package/.agent-context/rules/naming-conv.md +2 -0
- package/.agent-context/rules/performance.md +2 -0
- package/.agent-context/rules/security.md +1 -0
- package/.agent-context/rules/testing.md +1 -0
- package/lib/cli/project-scaffolder/design-contract/validation.mjs +4 -0
- package/lib/cli/project-scaffolder/design-contract.mjs +4 -0
- package/lib/cli/project-scaffolder/prompt-builders.mjs +5 -1
- package/package.json +1 -1
- package/scripts/frontend-usability-audit.mjs +4 -0
|
@@ -56,9 +56,7 @@ If the expressive path needs a new motion, 3D, canvas, scroll, or interaction li
|
|
|
56
56
|
|
|
57
57
|
Only downshift ambition after naming the concrete blocker: product fit, content density, measured performance budget, accessibility, device support, package conflict, security risk, or missing runtime capability. A new dependency, package count, or vague performance concern is not a blocker by itself. Pair every downshift with a replacement interaction quality that still changes composition, hierarchy, feedback, or memorability.
|
|
58
58
|
## Design Flexibility Layer
|
|
59
|
-
`docs/design-intent.json` must separate locked outcomes from flexible expression. The machine contract keeps review invariants stable; it must not freeze exact aesthetic implementation unless repo evidence, accessibility validation, implementation constraints, or explicit user approval locks it.
|
|
60
|
-
|
|
61
|
-
Record `designFlexibilityPolicy`: lock user goals, runtime constraints, accessibility, production readiness, forbidden patterns, and approved continuity; keep exact palette primitives, font families, radius/shadow values, component-kit theme mapping, signature move implementation, literal anchor artifacts, and spatial metaphors flexible until validated or approved. Semantic roles are required; exact primitives are not automatically locked. Required experience outcomes are separate from candidate implementation moves. Libraries supply behavior, accessibility, primitives, and delivery speed; the project supplies final composition, theme, morphology, and visual language.
|
|
59
|
+
`docs/design-intent.json` must separate locked outcomes from flexible expression. The machine contract keeps review invariants stable; it must not freeze exact aesthetic implementation unless repo evidence, accessibility validation, implementation constraints, or explicit user approval locks it. Record `designFlexibilityPolicy`: lock user goals, runtime constraints, accessibility, production readiness, forbidden patterns, and approved continuity; keep exact palette primitives, font families, radius/shadow values, component-kit theme mapping, signature move implementation, literal anchor artifacts, and spatial metaphors flexible until validated or approved. Semantic roles are required; exact primitives are not automatically locked.
|
|
62
60
|
## External Inspiration Boundary
|
|
63
61
|
Using outside websites, benchmark apps, galleries, or component examples is useful for constraint discovery, interaction mechanics, and implementation options, but never as a style source to imitate. Extract why a pattern works, then translate it into a current-project rule. Do not copy layout rhythm, palette, component skin, visual metaphor, or brand posture from a reference unless the user explicitly approves that continuity and it passes product fit.
|
|
64
62
|
|
|
@@ -83,16 +81,17 @@ If rich motion or spatial UI is omitted, record the product, content-density, pe
|
|
|
83
81
|
If 3D or canvas is used, record product role, interaction model, fallback path, runtime/library choice, loading state, keyboard path, and reduced-motion behavior.
|
|
84
82
|
|
|
85
83
|
## Token Derivation Audit
|
|
86
|
-
Before implementation, `docs/design-intent.json` must include top-level `derivedTokenLogic`:
|
|
87
|
-
- `anchorReference`
|
|
88
|
-
- `colorDerivationSource`
|
|
89
|
-
- `spacingDerivationSource`
|
|
90
|
-
- `typographyDerivationSource`
|
|
91
|
-
- `motionDerivationSource`
|
|
92
|
-
- `validationRule`
|
|
84
|
+
Before implementation, `docs/design-intent.json` must include top-level `derivedTokenLogic`: `anchorReference`, `colorDerivationSource`, `spacingDerivationSource`, `typographyDerivationSource`, `motionDerivationSource`, `colorSpace`, `spatialBaseUnit`, `typeScaleMethod`, `motionBudget`, and `validationRule`.
|
|
93
85
|
|
|
94
86
|
Every semantic token role must trace to `anchorReference`. Exact primitive values stay flexible until repo evidence, accessibility validation, implementation constraints, or explicit user approval locks them. If the rationale is "looks good", "common practice", "modern default", or "framework default", derive the token again before UI code.
|
|
95
87
|
|
|
88
|
+
## Implementation Craft Layer
|
|
89
|
+
Before accepting the design contract, record explicit CSS craft decisions:
|
|
90
|
+
- Color: prefer OKLCH tokens and tinted neutrals for new CSS when supported, preserve existing token formats, name color commitment level, derive scales as a perceptual lightness curve (not linear) with semantic role layers (surface, foreground, border, focus, status, data) before primary/secondary/accent, record one accessible text-on-color pair per interactive step, and treat dark mode as a second derived palette with its own lightness curve; record `color-scheme`, prefer `light-dark()` for theme-switch tokens, and record the no-flash and persistence strategy.
|
|
91
|
+
- Typography: prefer fluid `clamp()` scales with explicit role contrast, `text-wrap: balance`, and numeric typography decisions; treat type as a system rather than a font choice, recording one variable-axis decision (`wght`/`wdth`/`opsz` when available), one `font-feature-settings` choice tied to product role (tabular numerals for data, stylistic alternates or `case` for editorial voice), one measure (line-length budget), and an FOUT/FOIT strategy with `font-display` plus metric override when web fonts are loaded.
|
|
92
|
+
- Spatial/motion: name `spatialBaseUnit`, major multiples, optical exceptions, and `motionBudget`; prefer transform/opacity choreography, explicit easing, bounded stagger, and reduced-motion behavior.
|
|
93
|
+
- Implementation anti-attractor: list three default CSS reflexes this task might trigger, reject the most likely one, and choose one distinctive implementation move tied to the product.
|
|
94
|
+
|
|
96
95
|
## Library Research Protocol
|
|
97
96
|
If web search is available:
|
|
98
97
|
- Verify each new UI-related library against current official docs.
|
|
@@ -29,6 +29,8 @@ Use PRD, SRS, technical design, and ERD as conditional docs, not default boilerp
|
|
|
29
29
|
- Document the public surface before or alongside implementation.
|
|
30
30
|
- Machine-readable API contracts should use the current project standard. If unresolved, the LLM must recommend a current maintained option from official docs.
|
|
31
31
|
- HTTP APIs should prefer OpenAPI 3.1 when no stronger project standard exists.
|
|
32
|
+
- Choose transport (REST, GraphQL, tRPC, gRPC, SSE, WebSocket) and shape (resource-oriented vs action/command-oriented) from domain evidence, not by habit. When the domain has verbs such as cancel, refund, dispatch, approve, or retry, prefer command endpoints over awkward `PATCH` shoehorns and record at least one alternative transport considered.
|
|
33
|
+
- Treat HTTP as a behavioral contract, not just a shape. Document `ETag` and conditional requests for cacheable reads, `Cache-Control` and `Vary` when shared caches apply, rate-limit headers (`RateLimit-*` or `X-RateLimit-*`) with `Retry-After` when rate limiting exists, and require an `Idempotency-Key` request header on unsafe non-idempotent mutations.
|
|
32
34
|
- List endpoints must document pagination, limits, filtering, sorting, and empty-state behavior.
|
|
33
35
|
- Sensitive mutation endpoints must document idempotency behavior, retry safety, duplicate-submit handling, and any required idempotency key or request fingerprint.
|
|
34
36
|
- Public error contracts must document stable machine-readable codes and any RFC 9457 Problem Details-style fields the project exposes, including safe trace or correlation identifiers when present.
|
|
@@ -11,6 +11,7 @@ These principles are mandatory for backend and shared core modules.
|
|
|
11
11
|
- Readability over brevity.
|
|
12
12
|
- Keep transport, application, domain, and infrastructure concerns separated.
|
|
13
13
|
- Favor explicit module boundaries over hidden cross-layer shortcuts.
|
|
14
|
+
- Health endpoints distinguish liveness (the process is alive), readiness (the process can serve traffic), and startup (initialization complete) where the runtime supports it. A `200 OK` that does not check critical dependencies is not a readiness signal.
|
|
14
15
|
|
|
15
16
|
## Complexity Budget (Mandatory)
|
|
16
17
|
|
|
@@ -21,6 +22,7 @@ Prefer the smallest clear implementation that fully preserves behavior, safety,
|
|
|
21
22
|
- Prefer direct logic over extra wrappers, layers, classes, config, or state when the abstraction does not reduce real complexity.
|
|
22
23
|
- Keep validation, error handling, fallback paths, accessibility, tests, security boundaries, and observability when they protect real behavior.
|
|
23
24
|
- Run a final simplification pass before completion.
|
|
25
|
+
- Run a domain-fit pass on public contracts before completion: if endpoint names, payload fields, error codes, table names, or event types could be renamed to another domain without changing shape, the contract is too generic; revise to express the actual domain verbs and invariants. This is the backend equivalent of the design rename test.
|
|
24
26
|
- Do not optimize for line count alone.
|
|
25
27
|
- Do not replace clear code with clever, dense, or surprising code.
|
|
26
28
|
- Do not remove safeguards just because the happy path works.
|
|
@@ -17,6 +17,8 @@ Backend data access rules:
|
|
|
17
17
|
- Define maximum page size, payload size, and export limits so list responses cannot exhaust memory or connection pools.
|
|
18
18
|
- Mutations that write more than one table, aggregate, queue, or external consistency boundary must run inside a transaction or document the compensating recovery path.
|
|
19
19
|
- Repository and data-access layers own persistence mechanics. They must not hide business policy that belongs in application or domain logic.
|
|
20
|
+
- Index design follows read patterns, not column lists. Prefer composite indexes with selectivity-correct column order (equality before range), partial indexes for soft-delete or status-filtered tables, and covering indexes when a hot read can be satisfied without a heap fetch. Record the read pattern that justifies each non-trivial index.
|
|
21
|
+
- Record explicit decisions for delete semantics (hard delete, soft delete, append-only audit), tenant isolation (none, row-level with `tenant_id` plus row-level security, schema-per-tenant), and normalize-vs-denormalize trade-off for read-heavy or sparse data. Default to the simplest fit, but make the choice explicit in data docs rather than letting it become a side effect of the first migration.
|
|
20
22
|
- Cross-domain persistence must respect ownership boundaries. Independent services must not share database tables as an integration contract; modular monoliths may share one database only when module ownership and access paths stay explicit.
|
|
21
23
|
|
|
22
24
|
Docs must record entity ownership, relationships, constraints, data lifecycle, migration risk, and assumptions to validate.
|
|
@@ -16,5 +16,7 @@ Backend API error rules:
|
|
|
16
16
|
- Domain and validation errors should keep machine-readable codes so tests, clients, and operators can distinguish expected failures from defects.
|
|
17
17
|
- API boundary errors should include a safe correlation or trace identifier when observability exists, while protected logs keep the internal exception, actor, target, and trace context.
|
|
18
18
|
- Distributed systems should preserve trace context across ingress and egress using the project's tracing standard, such as W3C Trace Context or OpenTelemetry propagation.
|
|
19
|
+
- Prefer structured logging (key/value or JSON) over free-text strings, record at least one business metric per non-trivial operation alongside system metrics, and propagate correlation/trace IDs across async, queue, and worker boundaries.
|
|
20
|
+
- Distinguish error reporting from error recovery. For calls to unreliable upstreams, record the recovery strategy: retry with backoff and jitter, circuit-breaker thresholds and reset behavior, fallback path (cached value, default, degraded mode), and partial-failure semantics for batch operations (per-item success/failure rather than all-or-nothing). "Catch and log" is reporting, not recovery.
|
|
19
21
|
|
|
20
22
|
At boundaries, validate early, return safe user-facing errors, and keep machine-readable error context for operators and callers.
|
|
@@ -19,19 +19,7 @@ Use this rule for UI, UX, page, screen, component, layout, landing, dashboard, f
|
|
|
19
19
|
|
|
20
20
|
## Required Design Contract
|
|
21
21
|
|
|
22
|
-
Before UI code, create or refine `docs/DESIGN.md` and `docs/design-intent.json`.
|
|
23
|
-
|
|
24
|
-
The contract must record:
|
|
25
|
-
- `motionPaletteDecision`
|
|
26
|
-
- `designFlexibilityPolicy`
|
|
27
|
-
- `conceptualAnchor`
|
|
28
|
-
- `derivedTokenLogic`
|
|
29
|
-
- `aiSafeUiAudit`
|
|
30
|
-
- `designExecutionPolicy`
|
|
31
|
-
- `designExecutionHandoff`
|
|
32
|
-
- `reviewRubric`
|
|
33
|
-
- `contextHygiene`
|
|
34
|
-
- `libraryResearchStatus` and `libraryDecisions[]`
|
|
22
|
+
Before UI code, create or refine `docs/DESIGN.md` and `docs/design-intent.json`. The contract must record `motionPaletteDecision`, `designFlexibilityPolicy`, `conceptualAnchor`, `derivedTokenLogic`, `aiSafeUiAudit`, `designExecutionPolicy`, `designExecutionHandoff`, `reviewRubric`, `contextHygiene`, `libraryResearchStatus`, and `libraryDecisions[]`.
|
|
35
23
|
|
|
36
24
|
## Anti-Generic UI Gate
|
|
37
25
|
|
|
@@ -66,11 +54,13 @@ If the user gives no current-task visual research or reference:
|
|
|
66
54
|
- Product categories are heuristics, not style presets.
|
|
67
55
|
- Choose motion density from task, content density, brand intent, device budget, performance, and accessibility.
|
|
68
56
|
- Map states before coding: default, hover, focus-visible, active, disabled, loading, empty, error, success, transition.
|
|
57
|
+
- Distinguish motion (visual continuity between states) from interaction design (state machines, focus transfer on route/modal/error transitions, optimistic updates where safe, skeleton shapes that match real content, `aria-live` for status, keyboard paths, scroll-driven progressive disclosure). Record at least one interaction-design decision per major flow alongside motion choices.
|
|
69
58
|
- Prefer visually exploratory, product-derived palettes while preserving WCAG contrast and status clarity.
|
|
70
59
|
- Do not default to dark slate, cream/beige/tan, purple-blue gradients, monochrome palettes, cyber-neon terminals, or uniform card surfaces without product evidence.
|
|
71
60
|
- Treat motion, 3D, WebGL, canvas, scroll choreography, and animation libraries as first-class options.
|
|
72
61
|
- Omit rich motion or spatial UI only after naming the product-fit reason and the replacement interaction quality.
|
|
73
62
|
- For new screens or broad redesigns, research the expressive implementation path instead of defaulting to static native CSS. Use native or already-installed tools only when they can still deliver the chosen ambition, or when a concrete blocker is documented. Do not downshift because adding a package feels inconvenient; downshift only for a concrete product-fit, accessibility, security, compatibility, device, maintenance, or measured performance reason.
|
|
63
|
+
- Prefer micro-interactions in 150-300ms, layout transitions in 300-500ms, transform/opacity for high-frequency motion, explicit easing, bounded stagger, and reduced-motion alternatives unless evidence changes the budget.
|
|
74
64
|
- Keep reduced-motion, keyboard, loading, performance, mobile, and non-3D fallbacks explicit.
|
|
75
65
|
- Use component kits or headless primitives for behavior and accessibility when they fit. Replace library-default visual language with project-specific composition, tokens, motion, state treatment, and morphology.
|
|
76
66
|
- Keep design-intent flexible: lock user goals, accessibility, production readiness, forbidden patterns, and approved continuity; keep exact palette primitives, font families, radius/shadow values, component skins, candidate signature moves, and external website inspiration flexible until evidence or approval locks them. Convert references into product-fit rules; do not copy layout, palette, component skin, brand posture, or visual metaphor.
|
|
@@ -92,6 +82,7 @@ Responsive quality is not scale-only.
|
|
|
92
82
|
- Tablet must regroup surfaces instead of shrinking desktop.
|
|
93
83
|
- Desktop may expose more context but must not become interchangeable admin chrome.
|
|
94
84
|
- At least one major surface must change position, grouping, priority, or disclosure strategy between mobile and desktop.
|
|
85
|
+
- Prefer container queries, dynamic viewport units, support-checked selectors, subgrid, popover, or disclosure primitives when they simplify recomposition and fallbacks are clear.
|
|
95
86
|
|
|
96
87
|
## Accessibility
|
|
97
88
|
|
|
@@ -100,6 +91,13 @@ Responsive quality is not scale-only.
|
|
|
100
91
|
- Hard checks include focus visibility, focus appearance, target size, keyboard access, accessible authentication, color-only meaning, and dynamic status/state access.
|
|
101
92
|
- Fix accessibility issues without flattening the UI into generic safe chrome unless no expressive safe option remains.
|
|
102
93
|
|
|
94
|
+
## CSS Production Hardening
|
|
95
|
+
|
|
96
|
+
- Plan overflow, wrapping, truncation, empty, loading, error, and extreme-content behavior before declaring a layout complete.
|
|
97
|
+
- Prefer `min()`, `max()`, `clamp()`, stable aspect ratios, container-relative sizing, OKLCH, and tinted neutrals for new tokens when supported; preserve existing design-system tokens.
|
|
98
|
+
- Prefer composition primitives that match content meaning: named `grid-template-areas` for editorial regions, subgrid for nested alignment across siblings, container queries for component-level responsiveness independent of viewport, and explicit stacking context (`isolation: isolate`) when overlap or z-depth carries meaning. Do not default to flex column when content has structure that grid expresses better.
|
|
99
|
+
- Treat recursive card nesting, uniform radius everywhere, shadow on every surface, arbitrary spacing, gray text on saturated color, and library-default skins as drift signals requiring product rationale.
|
|
100
|
+
|
|
103
101
|
## Implementation Boundaries
|
|
104
102
|
|
|
105
103
|
- Follow the shipped project stack and current repo patterns.
|
|
@@ -9,3 +9,5 @@ Reject only these common LLM bad habits:
|
|
|
9
9
|
- booleans, units, and side-effect functions whose names hide what they represent or change
|
|
10
10
|
|
|
11
11
|
Prefer names that explain domain intent, user action, state, and boundary responsibility.
|
|
12
|
+
|
|
13
|
+
Inline comments must explain why, not what. Non-obvious choices (retry strategy, index column order, denormalized field, intentional swallow with named recovery, magic constant tied to an external system) deserve a one-line rationale near the code; comments that paraphrase the code are noise.
|
|
@@ -12,3 +12,5 @@ Hard rejections:
|
|
|
12
12
|
- caches without invalidation, expiry, ownership, and staleness trade-offs
|
|
13
13
|
|
|
14
14
|
When performance matters, measure the real bottleneck, change the smallest useful thing, and verify the result. Do not downshift product quality, UI ambition, or library fit from performance fear alone; name the concrete budget, bottleneck, device limit, or runtime evidence.
|
|
15
|
+
|
|
16
|
+
Caching is a tier decision before a technology decision. Prefer browser, CDN, or HTTP cache layers when data is shared and public; prefer in-process caches for hot per-instance data; reach for distributed caches such as Redis or Memcached only when shared mutable state across instances is the actual requirement. Record cache-aside, write-through, or write-behind shape, invalidation strategy, and stampede prevention (request coalescing or stale-while-revalidate) when the cache fronts an expensive backend.
|
|
@@ -14,6 +14,7 @@ Hard rules:
|
|
|
14
14
|
- retrieve secrets through environment, runtime secret injection, or the project's secret manager; do not store static secrets in source or plaintext config
|
|
15
15
|
- keep `.env` and local secret files covered by `.gitignore`; commit only safe examples such as `.env.example`
|
|
16
16
|
- treat transport encryption, secure cookies, and trusted proxy boundaries as deployment assumptions that must be documented when sensitive traffic is involved
|
|
17
|
+
- when a public surface exists, record explicit decisions for: CORS allow-list (not `*` for credentialed requests), security headers (CSP, HSTS, `X-Content-Type-Options`, `Referrer-Policy`, `Permissions-Policy`), JWT pitfalls (algorithm pinning, expiration, refresh rotation, storage location), webhook signature verification with timing-safe compare, SSRF defense (egress allow-list or URL validation) when the server fetches user-supplied URLs, and per-resource authorization (not role-only) when records have owners
|
|
17
18
|
|
|
18
19
|
Zero-trust API input rules:
|
|
19
20
|
- Treat body, query, params, headers, cookies, uploaded files, webhook payloads, and background job payloads as untrusted until validated.
|
|
@@ -15,6 +15,7 @@ Backend/API test rules:
|
|
|
15
15
|
- Event or worker changes must test retry, duplicate-message handling, dead-letter or recovery behavior, and outbox relay semantics when those paths exist.
|
|
16
16
|
- Distributed consistency changes must test the local transaction, publish/retry behavior, and compensating action or recovery path rather than only the happy path.
|
|
17
17
|
- Tests should make the API contract obvious from the fixture names, inputs, and expected response shape.
|
|
18
|
+
- Tests must exercise the failure paths the code claims to handle, not only the happy path. Prefer property-based or generated-input tests for invariants (validation, ordering, idempotency), explicit failure-injection tests for retry and recovery code, and contract tests at service boundaries when consumer and producer ownership is split.
|
|
18
19
|
|
|
19
20
|
Do not test framework internals, third-party library behavior, private implementation trivia, or snapshots that only freeze noise.
|
|
20
21
|
|
|
@@ -27,6 +27,10 @@ export function validateDesignContractCompleteness(designIntentContract) {
|
|
|
27
27
|
'spacingDerivationSource',
|
|
28
28
|
'typographyDerivationSource',
|
|
29
29
|
'motionDerivationSource',
|
|
30
|
+
'colorSpace',
|
|
31
|
+
'spatialBaseUnit',
|
|
32
|
+
'typeScaleMethod',
|
|
33
|
+
'motionBudget',
|
|
30
34
|
'validationRule',
|
|
31
35
|
]) {
|
|
32
36
|
if (!hasNonEmptyString(derivedTokenLogic[requiredFieldName])) {
|
|
@@ -334,6 +334,10 @@ function buildDesignIntentContractObject({
|
|
|
334
334
|
spacingDerivationSource: 'Explain spacing rhythm, density, and exceptions from anchorReference. Spacing grids are layout math, not decorative background lines.',
|
|
335
335
|
typographyDerivationSource: 'Explain display, body, metadata, and data roles from anchorReference.',
|
|
336
336
|
motionDerivationSource: 'Explain duration, easing, choreography, and reduced-motion from anchorReference.',
|
|
337
|
+
colorSpace: 'Prefer OKLCH for newly generated CSS tokens when supported; preserve existing design-system token formats and document fallback color space.',
|
|
338
|
+
spatialBaseUnit: 'Name the base spacing unit, major multiples, density exceptions, and optical exceptions before writing spacing values.',
|
|
339
|
+
typeScaleMethod: 'Prefer fluid clamp() type scales when supported; name ratio, role contrast, balance/wrap behavior, and numeric typography needs.',
|
|
340
|
+
motionBudget: 'Name micro, layout, entrance, easing, stagger, and reduced-motion budgets; prefer transform/opacity for high-frequency motion.',
|
|
337
341
|
validationRule: 'Every semantic token role must trace to anchorReference; keep exact primitive values flexible unless locked by repo evidence, accessibility validation, implementation constraints, or explicit user approval.',
|
|
338
342
|
},
|
|
339
343
|
motionPaletteDecision: {
|
|
@@ -245,10 +245,14 @@ export function buildDesignBootstrapPrompt({
|
|
|
245
245
|
'Use reduced-motion fallbacks instead of suppressing motion.',
|
|
246
246
|
'',
|
|
247
247
|
'## Token Derivation Audit',
|
|
248
|
-
'Before implementation, docs/design-intent.json must include derivedTokenLogic.anchorReference plus colorDerivationSource, spacingDerivationSource, typographyDerivationSource, motionDerivationSource, and validationRule.',
|
|
248
|
+
'Before implementation, docs/design-intent.json must include derivedTokenLogic.anchorReference plus colorDerivationSource, spacingDerivationSource, typographyDerivationSource, motionDerivationSource, colorSpace, spatialBaseUnit, typeScaleMethod, motionBudget, and validationRule.',
|
|
249
249
|
'Every semantic token role must be explainable from anchorReference. If the rationale is only looks good, common practice, modern default, or framework default, derive the token again before UI code.',
|
|
250
250
|
'Keep exact primitive values flexible until repo evidence, accessibility validation, implementation constraints, or explicit user approval locks them.',
|
|
251
251
|
'',
|
|
252
|
+
'## Implementation Craft Layer',
|
|
253
|
+
'Record explicit CSS craft decisions before UI code: color space and commitment level, fluid typography method, spacing base unit, motion budget, and the default CSS reflex this project rejects.',
|
|
254
|
+
'Prefer OKLCH, tinted neutrals, clamp() type scales, transform/opacity motion, and responsive recomposition when supported by the stack; preserve existing design-system tokens and document fallbacks instead of forcing rewrites.',
|
|
255
|
+
'',
|
|
252
256
|
'## Library Research Protocol',
|
|
253
257
|
'If web search is available, verify every new UI, animation, scroll, 3D, canvas, chart, icon, styling, or primitive library against current official docs and record source URL, fetched date, stable compatible version, purpose, risk, and fallback.',
|
|
254
258
|
'If web search is unavailable or fails, set libraryResearchStatus to pending-verification, record LIBRARY_TO_VERIFY notes, and use native CSS, browser APIs, or already-present project dependencies only when they can preserve the intended ambition until verification is possible.',
|
package/package.json
CHANGED
|
@@ -74,9 +74,12 @@ const REQUIRED_FRONTEND_RULE_SNIPPETS = [
|
|
|
74
74
|
'Prefer visually exploratory, product-derived palettes while preserving WCAG contrast and status clarity.',
|
|
75
75
|
'## Responsive Mutation',
|
|
76
76
|
'Responsive quality is not scale-only.',
|
|
77
|
+
'container queries',
|
|
77
78
|
'## Accessibility',
|
|
78
79
|
'WCAG 2.2 AA is the hard floor.',
|
|
79
80
|
'APCA is advisory perceptual tuning only.',
|
|
81
|
+
'## CSS Production Hardening',
|
|
82
|
+
'overflow, wrapping, truncation',
|
|
80
83
|
'## Implementation Boundaries',
|
|
81
84
|
'Do not hardcode Zustand, React Query, smart/dumb component doctrine',
|
|
82
85
|
];
|
|
@@ -89,6 +92,7 @@ const REQUIRED_BOOTSTRAP_DESIGN_SNIPPETS = [
|
|
|
89
92
|
'repoEvidence.designEvidenceSummary',
|
|
90
93
|
'research current official docs',
|
|
91
94
|
'Responsive design means recomposition, not resizing.',
|
|
95
|
+
'Implementation Craft Layer',
|
|
92
96
|
'agent-chosen visual direction',
|
|
93
97
|
'viewport mutation rules',
|
|
94
98
|
'WCAG 2.2 AA is the hard floor',
|