arkaos 4.28.0 → 4.29.0
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/THE-ARKAOS-GUIDE.md +1 -1
- package/VERSION +1 -1
- package/arka/skills/refine/SKILL.md +7 -0
- package/config/claude-agents/brand-director.md +1 -1
- package/config/claude-agents/design-ops-lead.md +1 -1
- package/config/claude-agents/frontend-dev.md +1 -1
- package/config/claude-agents/ux-designer.md +1 -1
- package/config/claude-agents/ux-strategist.md +1 -1
- package/config/claude-agents/visual-designer.md +1 -1
- package/config/claude-agents/wcag-auditor.md +1 -1
- package/config/skills-provenance.yaml +14 -2
- package/departments/brand/agents/brand-director.yaml +2 -0
- package/departments/brand/agents/design-ops/design-ops-lead.yaml +2 -0
- package/departments/brand/agents/design-ops/wcag-auditor.yaml +2 -0
- package/departments/brand/agents/ux-designer.yaml +2 -0
- package/departments/brand/agents/ux-strategist.yaml +2 -0
- package/departments/brand/agents/visual-designer.yaml +2 -0
- package/departments/brand/references/uiux-knowledge-and-tools.md +185 -2
- package/departments/brand/skills/design-review/SKILL.md +25 -0
- package/departments/brand/skills/design-review/references/anti-patterns.md +420 -0
- package/departments/brand/skills/design-review/references/critique-protocol.md +169 -0
- package/departments/brand/skills/design-review/references/design-registers.md +181 -0
- package/departments/brand/skills/design-review/references/genres/atmospheric.md +71 -0
- package/departments/brand/skills/design-review/references/genres/editorial.md +74 -0
- package/departments/brand/skills/design-review/references/genres/modern-minimal.md +73 -0
- package/departments/brand/skills/design-review/references/genres/playful.md +72 -0
- package/departments/brand/skills/design-review/references/hallmark.LICENSE +21 -0
- package/departments/brand/skills/design-review/references/impeccable.LICENSE +191 -0
- package/departments/brand/skills/design-review/references/impeccable.NOTICE +11 -0
- package/departments/brand/skills/design-review/references/slop-test.md +194 -0
- package/departments/brand/skills/ux-audit/SKILL.md +25 -4
- package/departments/dev/agents/frontend-dev.yaml +2 -0
- package/harness/codex/AGENTS.md +1 -1
- package/harness/copilot/copilot-instructions.md +1 -1
- package/harness/cursor/rules/arkaos.mdc +2 -2
- package/harness/gemini/GEMINI.md +1 -1
- package/harness/opencode/AGENTS.md +1 -1
- package/harness/zed/.rules +1 -1
- package/knowledge/agents-registry-v2.json +19 -5
- package/knowledge/skills-manifest.json +7 -3
- package/package.json +1 -1
- package/pyproject.toml +1 -1
|
@@ -0,0 +1,191 @@
|
|
|
1
|
+
Apache License
|
|
2
|
+
Version 2.0, January 2004
|
|
3
|
+
http://www.apache.org/licenses/
|
|
4
|
+
|
|
5
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
6
|
+
|
|
7
|
+
1. Definitions.
|
|
8
|
+
|
|
9
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
10
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
11
|
+
|
|
12
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
13
|
+
the copyright owner that is granting the License.
|
|
14
|
+
|
|
15
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
16
|
+
other entities that control, are controlled by, or are under common
|
|
17
|
+
control with that entity. For the purposes of this definition,
|
|
18
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
19
|
+
direction or management of such entity, whether by contract or
|
|
20
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
21
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
22
|
+
|
|
23
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
24
|
+
exercising permissions granted by this License.
|
|
25
|
+
|
|
26
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
27
|
+
including but not limited to software source code, documentation
|
|
28
|
+
source, and configuration files.
|
|
29
|
+
|
|
30
|
+
"Object" form shall mean any form resulting from mechanical
|
|
31
|
+
transformation or translation of a Source form, including but
|
|
32
|
+
not limited to compiled object code, generated documentation,
|
|
33
|
+
and conversions to other media types.
|
|
34
|
+
|
|
35
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
36
|
+
Object form, made available under the License, as indicated by a
|
|
37
|
+
copyright notice that is included in or attached to the work
|
|
38
|
+
(an example is provided in the Appendix below).
|
|
39
|
+
|
|
40
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
41
|
+
form, that is based on (or derived from) the Work and for which the
|
|
42
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
43
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
44
|
+
of this License, Derivative Works shall not include works that remain
|
|
45
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
46
|
+
the Work and Derivative Works thereof.
|
|
47
|
+
|
|
48
|
+
"Contribution" shall mean any work of authorship, including
|
|
49
|
+
the original version of the Work and any modifications or additions
|
|
50
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
51
|
+
submitted to the Licensor for inclusion in the Work by the copyright
|
|
52
|
+
owner or by an individual or Legal Entity authorized to submit on
|
|
53
|
+
behalf of the copyright owner. For the purposes of this definition,
|
|
54
|
+
"submitted" means any form of electronic, verbal, or written
|
|
55
|
+
communication sent to the Licensor or its representatives, including
|
|
56
|
+
but not limited to communication on electronic mailing lists, source
|
|
57
|
+
code control systems, and issue tracking systems that are managed by,
|
|
58
|
+
or on behalf of, the Licensor for the purpose of discussing and
|
|
59
|
+
improving the Work, but excluding communication that is conspicuously
|
|
60
|
+
marked or otherwise designated in writing by the copyright owner as
|
|
61
|
+
"Not a Contribution."
|
|
62
|
+
|
|
63
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
64
|
+
on behalf of whom a Contribution has been received by Licensor and
|
|
65
|
+
subsequently incorporated within the Work.
|
|
66
|
+
|
|
67
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
68
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
69
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
70
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
71
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
72
|
+
Work and such Derivative Works in Source or Object form.
|
|
73
|
+
|
|
74
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
75
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
76
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
77
|
+
(except as stated in this section) patent license to make, have made,
|
|
78
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
79
|
+
where such license applies only to those patent claims licensable
|
|
80
|
+
by such Contributor that are necessarily infringed by their
|
|
81
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
82
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
83
|
+
institute patent litigation against any entity (including a
|
|
84
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
85
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
86
|
+
or contributory patent infringement, then any patent licenses
|
|
87
|
+
granted to You under this License for that Work shall terminate
|
|
88
|
+
as of the date such litigation is filed.
|
|
89
|
+
|
|
90
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
91
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
92
|
+
modifications, and in Source or Object form, provided that You
|
|
93
|
+
meet the following conditions:
|
|
94
|
+
|
|
95
|
+
(a) You must give any other recipients of the Work or
|
|
96
|
+
Derivative Works a copy of this License; and
|
|
97
|
+
|
|
98
|
+
(b) You must cause any modified files to carry prominent notices
|
|
99
|
+
stating that You changed the files; and
|
|
100
|
+
|
|
101
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
102
|
+
that You distribute, all copyright, patent, trademark, and
|
|
103
|
+
attribution notices from the Source form of the Work,
|
|
104
|
+
excluding those notices that do not pertain to any part of
|
|
105
|
+
the Derivative Works; and
|
|
106
|
+
|
|
107
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
108
|
+
distribution, then any Derivative Works that You distribute must
|
|
109
|
+
include a readable copy of the attribution notices contained
|
|
110
|
+
within such NOTICE file, excluding those notices that do not
|
|
111
|
+
pertain to any part of the Derivative Works, in at least one
|
|
112
|
+
of the following places: within a NOTICE text file distributed
|
|
113
|
+
as part of the Derivative Works; within the Source form or
|
|
114
|
+
documentation, if provided along with the Derivative Works; or,
|
|
115
|
+
within a display generated by the Derivative Works, if and
|
|
116
|
+
wherever such third-party notices normally appear. The contents
|
|
117
|
+
of the NOTICE file are for informational purposes only and
|
|
118
|
+
do not modify the License. You may add Your own attribution
|
|
119
|
+
notices within Derivative Works that You distribute, alongside
|
|
120
|
+
or as an addendum to the NOTICE text from the Work, provided
|
|
121
|
+
that such additional attribution notices cannot be construed
|
|
122
|
+
as modifying the License.
|
|
123
|
+
|
|
124
|
+
You may add Your own copyright statement to Your modifications and
|
|
125
|
+
may provide additional or different license terms and conditions
|
|
126
|
+
for use, reproduction, or distribution of Your modifications, or
|
|
127
|
+
for any such Derivative Works as a whole, provided Your use,
|
|
128
|
+
reproduction, and distribution of the Work otherwise complies with
|
|
129
|
+
the conditions stated in this License.
|
|
130
|
+
|
|
131
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
132
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
133
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
134
|
+
this License, without any additional terms or conditions.
|
|
135
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
136
|
+
the terms of any separate license agreement you may have executed
|
|
137
|
+
with Licensor regarding such Contributions.
|
|
138
|
+
|
|
139
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
140
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
141
|
+
except as required for reasonable and customary use in describing the
|
|
142
|
+
origin of the Work and reproducing the content of the NOTICE file.
|
|
143
|
+
|
|
144
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
145
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
146
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
147
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
148
|
+
implied, including, without limitation, any warranties or conditions
|
|
149
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
150
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
151
|
+
appropriateness of using or redistributing the Work and assume any
|
|
152
|
+
risks associated with Your exercise of permissions under this License.
|
|
153
|
+
|
|
154
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
155
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
156
|
+
unless required by applicable law (such as deliberate and grossly
|
|
157
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
158
|
+
liable to You for damages, including any direct, indirect, special,
|
|
159
|
+
incidental, or consequential damages of any character arising as a
|
|
160
|
+
result of this License or out of the use or inability to use the
|
|
161
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
162
|
+
work stoppage, computer failure or malfunction, or any and all
|
|
163
|
+
other commercial damages or losses), even if such Contributor
|
|
164
|
+
has been advised of the possibility of such damages.
|
|
165
|
+
|
|
166
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
167
|
+
the Work or Derivative Works thereof, You may choose to offer,
|
|
168
|
+
and charge a fee for, acceptance of support, warranty, indemnity,
|
|
169
|
+
or other liability obligations and/or rights consistent with this
|
|
170
|
+
License. However, in accepting such obligations, You may act only
|
|
171
|
+
on Your own behalf and on Your sole responsibility, not on behalf
|
|
172
|
+
of any other Contributor, and only if You agree to indemnify,
|
|
173
|
+
defend, and hold each Contributor harmless for any liability
|
|
174
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
175
|
+
of your accepting any such warranty or additional liability.
|
|
176
|
+
|
|
177
|
+
END OF TERMS AND CONDITIONS
|
|
178
|
+
|
|
179
|
+
Copyright 2025 Paul Bakaus
|
|
180
|
+
|
|
181
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
182
|
+
you may not use this file except in compliance with the License.
|
|
183
|
+
You may obtain a copy of the License at
|
|
184
|
+
|
|
185
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
186
|
+
|
|
187
|
+
Unless required by applicable law or agreed to in writing, software
|
|
188
|
+
distributed under the License is distributed on an "AS IS" BASIS,
|
|
189
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
190
|
+
See the License for the specific language governing permissions and
|
|
191
|
+
limitations under the License.
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
# Third-Party Notices
|
|
2
|
+
|
|
3
|
+
This project includes content derived from third-party work, used under the terms of its original license.
|
|
4
|
+
|
|
5
|
+
## Platform Design Skills
|
|
6
|
+
|
|
7
|
+
The `skill/reference/ios.md` and `skill/reference/android.md` platform reference files are distilled from ehmo's `platform-design-skills` (Apple Human Interface Guidelines and Material Design 3 rules), rewritten in Impeccable's voice.
|
|
8
|
+
|
|
9
|
+
**Original work:** https://github.com/ehmo/platform-design-skills
|
|
10
|
+
**Original license:** MIT
|
|
11
|
+
**Author:** ehmo
|
|
@@ -0,0 +1,194 @@
|
|
|
1
|
+
# Slop test — 58 gates + pre-emit self-critique
|
|
2
|
+
|
|
3
|
+
> Derived from [hallmark](https://github.com/nutlope/hallmark) (MIT — see `hallmark.LICENSE` in this directory). Sanitized and adapted for ArkaOS.
|
|
4
|
+
|
|
5
|
+
Run this list before handing back any output. Every answer must be **no**. Record the actual outcome of this run in the `[arka:design-dna]` stamp (squad reference §9).
|
|
6
|
+
|
|
7
|
+
Some gates are **universal** (apply to every genre); some are **genre-scoped** (apply only when the active genre is editorial, atmospheric, modern-minimal, or playful). Genre overrides are noted inline. Where a gate has *no* genre note, treat it as universal.
|
|
8
|
+
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
## Pre-emit self-critique (six axes)
|
|
12
|
+
|
|
13
|
+
Run this **before** the gate list, not after. Score the planned output 1–5 on each axis. Anything **< 3 on any axis triggers a revision pass** before the gate sweep — don't bring known weakness into a fifty-eight-gate review.
|
|
14
|
+
|
|
15
|
+
Two passes is normal. Three is a sign the brief is wrong, not the design — re-read the brief.
|
|
16
|
+
|
|
17
|
+
| # | Axis | What you're scoring |
|
|
18
|
+
|---|---|---|
|
|
19
|
+
| **A** | **Philosophy** | Is there a clear *why* — a position the page is taking? Or is it just a layout? |
|
|
20
|
+
| **B** | **Hierarchy** | Can a reader tell, in 2 seconds, what's primary, secondary, tertiary? Or is everything the same weight? |
|
|
21
|
+
| **C** | **Execution** | Are the details (rule weight, accent footprint, text-wrap, focus rings, contrast) all in spec, or is there sloppiness even if the bones are right? |
|
|
22
|
+
| **D** | **Specificity** | Does this look like *this brief* — or does it look like a generic "page that could be anyone"? |
|
|
23
|
+
| **E** | **Restraint** | Have you removed everything that isn't earning its place? Decoration, redundancy, padding-for-padding's-sake? |
|
|
24
|
+
| **F** | **Variety** | Does this output share a structural fingerprint with a previous ArkaOS design output in the project? Score by structural distance, not visual distance — colour-swaps don't count as variety. |
|
|
25
|
+
|
|
26
|
+
Record the six scores in a one-line stamp comment at the top of the file: `/* [arka:design-dna] macrostructure=<name> genre=<g> anchor=<oklch> display=<font> body=<font> critique=P5H4E5S4R5V5 */`. Future runs should be able to find this and avoid repeating the same weakness.
|
|
27
|
+
|
|
28
|
+
---
|
|
29
|
+
|
|
30
|
+
## Visual
|
|
31
|
+
|
|
32
|
+
1. Is the display font on the reflex-reject list? The canonical reflex-reject font list lives in `departments/brand/references/uiux-knowledge-and-tools.md` §11 — check against it; never restate it here.
|
|
33
|
+
2. Is there a purple-to-blue (or cyan-to-magenta) gradient anywhere — **including a `background-clip: text` gradient headline**? (see doctrine hub §12 absolute bans) *Genre note: atmospheric allows radial gradients on background only — never on text or pill buttons. No genre allows gradient text.*
|
|
34
|
+
3. Is there a 3-equal-column card grid with icon-above-heading tiles?
|
|
35
|
+
4. Is any card nested inside another card?
|
|
36
|
+
5. Is any card using a thick coloured left/right side-stripe border?
|
|
37
|
+
6. **Hero shape — centred-everything.** Is the hero `min-height: 100vh` with everything centred, OR are the eyebrow, title, lede, AND CTA all stacked on the same centred vertical axis? Auto-fail. Pick at most two centred elements and break alignment for the rest; the eyebrow or CTA should sit off-axis (margin-aligned, right-flush, numeral-anchored). *Genre note: atmospheric and playful allow a centred hero when the canvas itself is the design (Suno-style); editorial / atelier allow a centred-narrow hero, but even then the eyebrow or CTA sits off-axis.*
|
|
38
|
+
7. Is pure `#000` or pure `#fff` used as a base colour anywhere? *Genre note: modern-minimal allows pure `#fff` paper (the Stripe / ElevenLabs school).*
|
|
39
|
+
|
|
40
|
+
## Structural
|
|
41
|
+
|
|
42
|
+
8. Does the page reuse a structure it shouldn't — either the generic AI template (Hero → 3 features → CTA → footer), **or** the *same* structural fingerprint / macrostructure as a previous ArkaOS design output in this project? Read the file system: if a `.arka/design/log.json` entry or a CSS macrostructure stamp exists, this build's macrostructure must differ from the last.
|
|
43
|
+
9. Are sections separated only by equal whitespace, with no rule, no ornament, no colour shift — every section identical in rhythm?
|
|
44
|
+
|
|
45
|
+
## Microinteractions
|
|
46
|
+
|
|
47
|
+
10. Is `transition-all` (or `transition: all`) used anywhere? (Specify the properties.)
|
|
48
|
+
11. Is `hover:scale-105` (or any uniform hover-scale) applied across multiple unrelated elements?
|
|
49
|
+
12. Are bouncy / overshoot easings (`cubic-bezier(0.34, 1.56, ...)`, etc.) used on UI state changes — buttons, modals, tooltips? (Reserve overshoots for physical interactions only.)
|
|
50
|
+
13. Does any element have *more than one* hover effect at the same time (translate + scale + shadow + colour + rotate)?
|
|
51
|
+
14. Are you animating `width`, `height`, `top`, `left`, `margin`, or `padding` anywhere?
|
|
52
|
+
15. Does the focus ring transition into existence (fade in)? (Focus rings must appear instantly — keyboard users need an immediate indicator.)
|
|
53
|
+
16. Is there a celebratory success toast for an action whose effect the user can already see? (Silent success is taste; toasts are for failures and invisible effects.)
|
|
54
|
+
17. Are tooltip hover-delay and focus-delay equal? (Hover should delay 800–1000 ms; focus should be 0 ms.)
|
|
55
|
+
18. Is auto-rotating content (carousel, banner, stats) lacking pause-on-hover-and-focus? (WCAG 2.2.2.)
|
|
56
|
+
19. Is there a placeholder name "Jane Doe / John Smith" or a startup cliché (Acme, Nexus, Seamless, Unleash)?
|
|
57
|
+
|
|
58
|
+
## Variety
|
|
59
|
+
|
|
60
|
+
20. Is the `/* [arka:design-dna] macrostructure=<name> ... */` stamp missing from the top of the CSS? (It must be present.)
|
|
61
|
+
21. Did I default to the **Specimen** macrostructure (numbered left-margin labels + huge serif + asymmetric spans + typographic-only CTA) when the brief did not explicitly call for editorial / foundry / specimen energy? (Specimen fall-through is banned.) (see doctrine hub §8) *Genre note: atmospheric, modern-minimal, and playful never default to Specimen — only editorial does, and only when the brief signals it.*
|
|
62
|
+
|
|
63
|
+
## Implementation gates
|
|
64
|
+
|
|
65
|
+
22. Does any neutral / surface colour have `oklch(... 0 ...)` (zero chroma)? Pure greys read as flat. Tint every neutral toward the anchor hue — minimum 0.005 chroma. *Genre note: modern-minimal allows zero-chroma neutrals (the monochrome Stripe / ElevenLabs school).*
|
|
66
|
+
23. Does the accent colour cover more than ~5 % of any single viewport (count by area: solid fills, large headings in accent, full-bleed accent backgrounds)? If yes, retreat — accent is for emphasis, not for filling. *Genre note: atmospheric allows accent-tinted radial blooms covering up to ~20 % of the canvas, since the bloom is the design.*
|
|
67
|
+
24. Is any padding / gap / margin a value that isn't on the named spacing scale (`--space-3xs` … `--space-5xl`, multiples of 4 px)? Arbitrary `padding: 17px` is a tell.
|
|
68
|
+
25. Is any prose container's `max-width` outside the 45–75 ch range? Measure must read; under 45 ch is choppy, over 75 ch loses the eye.
|
|
69
|
+
26. Does any interactive element lack `:focus-visible`, `:active`, OR `:disabled` styling? (Eight states is the rule. Default + hover is two; you need at least default + hover + focus-visible + active + disabled present in code.)
|
|
70
|
+
27. Is there any `transform` / `animation` keyframe that is NOT covered by a `@media (prefers-reduced-motion: reduce)` fallback? Every motion gets a reduced-motion alternative.
|
|
71
|
+
|
|
72
|
+
## Hero enrichment gates
|
|
73
|
+
|
|
74
|
+
(When the page carries enrichment — see `hero-enrichment.md`.)
|
|
75
|
+
|
|
76
|
+
28. If the page has a demo video, does it autoplay with sound, lack a `poster`, lack `fetchpriority="high"`, or use `loading="lazy"` on the LCP element? (LCP-killers fail this gate.)
|
|
77
|
+
29. If the page has an abstract background, is it more than one accent colour, more than ~5 % footprint, or animating mesh-gradient on the whole page? (Aurora blobs and mesh-on-everything fail this gate.) *Genre note: atmospheric allows up to two warm-toned radial blooms covering ~20–30 % of the canvas, fixed-attached, no animation.*
|
|
78
|
+
30. **Icon tells.** Does the page (a) mix two or more icon libraries (Material + Heroicons + Lucide on the same page), OR (b) use an emoji glyph (✨ 🚀 ⚡ 🔥 🎯 ✅) as a feature-card / value-prop / step / pricing-tier icon? Either is an AI-default tell. Pick one icon library (Lucide / Phosphor / Heroicons — see `assets.md`), build a custom SVG, or drop the icon and lead with typography.
|
|
79
|
+
31. If the page has illustration, did I default to a Lottie library when a hand-built SVG or pure-CSS shape would have worked? (Lottie is last resort, not the default.)
|
|
80
|
+
|
|
81
|
+
## Diversification gates
|
|
82
|
+
|
|
83
|
+
(Cross-reference `.arka/design/log.json` when present.)
|
|
84
|
+
|
|
85
|
+
32. If I used the same archetype as a previous ArkaOS design output (per `.arka/design/log.json` or the latest macrostructure stamp), did I pick at least one different *variation knob*? Two Bento Grids with `tiles=6, spans=irregular, accent=corner-only` are the same Bento — the within-archetype knobs in `component-cookbook.md` exist precisely to prevent that. State the knob deltas in the stamp.
|
|
86
|
+
33. Does any visual-only `<svg>`, custom-art `<div>`, `<canvas>`, or decorative figure lack `aria-label` or `aria-hidden="true"`? Hand-built CSS art and SVG illustrations need an accessible name *or* an explicit hide. Skipping this is the new accessibility tell.
|
|
87
|
+
|
|
88
|
+
## Layout-safety gates
|
|
89
|
+
|
|
90
|
+
(The page must survive every viewport.)
|
|
91
|
+
|
|
92
|
+
34. Does the page horizontally scroll on any viewport between 320 px and 1920 px? Open the rendered page; drag the dev-tools width slider across that range. If a horizontal scrollbar appears at any width, fail. The required fix is `overflow-x: clip` on **both** `html` and `body` — use `clip`, not `hidden` (`clip` preserves `position: sticky` and `position: fixed` on descendants). This is a hard requirement on every emitted page, not only when scroll is observed. (Cross-reference: `layout-and-space.md` § Page-edge clipping.)
|
|
93
|
+
35. For every decorative effect on text — highlighter `<mark>` / `<em>` band / accent stroke / underline — did I visually confirm the position and size? A highlighter band must sit behind the x-height (`linear-gradient(180deg, transparent ~38%, accent ~38%, accent ~92%, transparent ~92%)`), **not** at the baseline (which reads as a fat underline). Underlines must be 1–2 px and offset 1–2 px from the baseline, never 5+ px. Decorative strokes must not exceed 5 % of the viewport (gate 23). The check is *visual*: imagine the rendered output and confirm the band lands in the right vertical zone.
|
|
94
|
+
36. Are interactive bars (nav, toolbar, command bar, hero CTA row, footer link strip) explicitly vertically centered? Default flex layouts inherit `align-items: stretch`, which makes a button taller than its sibling text and breaks the visual baseline. Every flex row mixing height-different elements (button + text, icon + text, mark + body) must declare `align-items: center` and `line-height: 1` on the items with intrinsic height. Inheriting `line-height: 1.55` from `html` fights the row's vertical rhythm.
|
|
95
|
+
|
|
96
|
+
## Typography discipline gates
|
|
97
|
+
|
|
98
|
+
(Three faces is the ceiling. See `typography.md` § The 2+1 rule.)
|
|
99
|
+
|
|
100
|
+
37. Does the page use **more than three** distinct `font-family` families? Count: `--font-display`, `--font-body`, and at most one outlier (`--font-outlier` for wordmark / hero stat / pull quote). A fourth family on the page — e.g. body + display + mono in code blocks + a separate display for the hero — is slop. Same family at different weights counts as one family. Mono counts as a family if used in any non-code context (captions, labels, numerals). If you find four, drop one back to the body or display face.
|
|
101
|
+
38. Is the **outlier face used in more than two slots** on the page? The outlier is a register, not a third surface — wordmark + hero stat is the canonical pair, or wordmark + masthead, or hero stat + pull quote. Three slots = the outlier is now a third body font; collapse it back to the body face.
|
|
102
|
+
38a. Is any **heading or display type italic** (`font-style: italic` on `h1`–`h6`, a `.*__title`, `.hero__title`, a wordmark, a stat figure, a footer statement, or an `<em>`/`<i>` inside a heading)? If yes, fail. Italic headers — above all the single italicised emphasis-word inside an upright headline — are a top AI tell. Headers are roman; emphasis comes from weight, accent colour, or a drawn underline. Italic is allowed *only* as body-copy emphasis inside running paragraphs. (Applies to every theme; Studio / Garden / Sport — historically italic-display — are reworked to roman.)
|
|
103
|
+
|
|
104
|
+
## Input-state gate
|
|
105
|
+
|
|
106
|
+
(Inputs are where almost-right UIs lose. See `interaction-and-states.md` § Input field states.)
|
|
107
|
+
|
|
108
|
+
39. Do input / textarea / select fields handle every state correctly? Fail on **any** of these five:
|
|
109
|
+
- **Border-width shifts between states** — default / hover / focus / error must all keep `border-width: 1px`. State changes go to `background-color`, `outline`, `box-shadow`, or `border-color` — never `border-width` (it shifts layout).
|
|
110
|
+
- **Focus ring built from `border` instead of `outline`** — must be `outline: 2px solid var(--color-focus)` with `outline-offset: 1px`; reserve `outline: 2px solid transparent` at rest to prevent geometry shift on activate.
|
|
111
|
+
- **Input height ≠ adjacent button height** on the same form — share one base height (44 px floor); 38 px input + 44 px button is the most common form-tuning slop.
|
|
112
|
+
- **Helper-text slot collapses when empty** — reserve `min-height: 1lh` even with no helper / error, so an appearing error doesn't push the page down.
|
|
113
|
+
- **Disabled signalled by `opacity` alone** — disabled needs three channels: `opacity: 0.55` AND `cursor: not-allowed` AND the native `disabled` attribute (or `aria-disabled="true"`).
|
|
114
|
+
|
|
115
|
+
## Contrast & readability
|
|
116
|
+
|
|
117
|
+
Universal — apply to every genre. These gates catch the real-world failures the user flagged: black-text-on-black-button, dark sections with unreadable text, ink-on-ink slop where the LLM forgot to flip the text colour after flipping the surface.
|
|
118
|
+
|
|
119
|
+
Contrast computation: for every `(color, background-color)` pair on the page, run **APCA Lc** OR **WCAG 2.1 ratio**. OKLCH lightness is a fast pre-check — if `|L_text − L_bg| < 50 %`, the pair likely fails 4.5:1 — confirm with a full calculation.
|
|
120
|
+
|
|
121
|
+
40. **Contrast thresholds.** Does any text, icon, or `:focus-visible` ring fail its threshold against its *computed* background? Pair every `color` declaration with its effective `background-color` and verify. Thresholds: **body text** (under 24 px regular OR under 18 px bold) needs **WCAG 4.5:1 / APCA Lc ≥ 60**; **large text** (≥ 24 px regular / ≥ 18 px bold), **icons**, and **focus rings** need **WCAG 3:1 / APCA Lc ≥ 45**. The most-missed cases: text inside a card that inherits `color` but the card switched to `background: var(--color-paper-2)`; muted text (`var(--color-muted)`) on `var(--color-paper-3)`; a focus ring whose `--color-focus` clears 3:1 against the element but not the page surface.
|
|
122
|
+
|
|
123
|
+
41. **The contrast failures that ship most often.** Fail on **any**:
|
|
124
|
+
- **Button text ≈ button fill** — if the computed text colour and fill are within **5 % lightness AND 0.05 chroma** in OKLCH, fail. This catches the black-on-black bug (`color: var(--color-ink)` on `background: var(--color-ink)` — the model forgot `--color-accent-ink` / `--color-paper`).
|
|
125
|
+
- **`--color-accent-ink` missing or unused** — whenever `--color-accent` fills a surface that carries text, `--color-accent-ink` must be defined, verify ≥ APCA Lc 60 / WCAG 4.5:1 against `--color-accent`, and be applied as the `color` on that fill.
|
|
126
|
+
- **Dark-section ink-on-ink** — any section / panel whose `background-color` is OKLCH lightness < 50 % must also swap its text colour (typically to `--color-paper`) and ensure nested children inherit. A class that sets `background: <dark>` must set `color: <light>` in the same rule (or be wrapped in a parent that does). Common failure: a `.vs__col:first-child` painted with accent / ink but the inner panels still using default ink-coloured text.
|
|
127
|
+
|
|
128
|
+
The `[arka:design-dna]` stamp should record the result: `contrast=pass(40–41)` if both gates pass, or `contrast=FAIL gates <list>` if any are open. Fix before shipping.
|
|
129
|
+
|
|
130
|
+
## Nav · footer · hero structural slop
|
|
131
|
+
|
|
132
|
+
Universal — apply to every genre. These gates catch the most-recognised AI fingerprints in nav, footer, and hero shape. They sit alongside the structural-fingerprint gate (gate 8): gate 8 catches the *page* fingerprint; 42–45 catch the *chrome* fingerprints that sit on top of it.
|
|
133
|
+
|
|
134
|
+
42. **Nav fingerprint.** Is the page's `<nav>` (or top-of-page `<header>` with role="banner") the AI default — wordmark-left + 4–5 inline text links centred-or-right + button-right at full viewport width + 1 px hairline border-bottom + white background? If yes, fail unless the brief explicitly justifies N1a (the page has only 2 destinations *and* the routing table for the genre allows N1a). ArkaOS design output should rotate among N1b, N2, N3, N4, N5, N6, N7, N8, N9, N10, N11, N12, N13 from `component-cookbook.md` § Navigation.
|
|
135
|
+
|
|
136
|
+
43. **Footer fingerprint.** Is the `<footer>` the AI default — 4 columns of links (Product / Company / Resources / Legal) + social-icon row + tiny copyright at the very bottom + 1 px hairline top-border + neutral grey background? If yes, fail unless the page is a genuine docs root or hub. Default to Ft1, Ft2, Ft4, Ft5, Ft6, Ft7, or Ft8 from `component-cookbook.md` § Footers.
|
|
137
|
+
|
|
138
|
+
44. **Hero fit — sits into the page and fits the fold.** Two checks, both on the rendered hero: (a) Is `padding-block-end` ≥ 1.3× `padding-block-start`? Symmetric or top-heavy padding makes the hero float off the page; heavier bottom padding pulls it into the next section's rhythm. (b) On a standard laptop viewport — test at **1280×800** (13″), not just 1440×900 — can the hero's essential content (eyebrow, headline, lede, **and the primary CTA**, plus any hero visual's focal point) all be seen **without scrolling**? This is the other half of gate 6 (which caps the hero's *shape*): this caps its *content*. A hero can satisfy `min-height` and still overflow because the content is intrinsically too tall — usual culprits are an **oversized display clamp**, **loose line-height** (display at ~1.2 instead of 1.0–1.1), a **lede that runs 3+ lines**, or **bloated `padding-block`**. Right-size to the fold: pull the display `clamp()` max down until the headline fits 2–3 lines, set display line-height 1.0–1.1, hold the lede to ~2 lines (≤ ~60 ch), trim hero padding. **Don't overcorrect:** a hero that already fits passes untouched — this never means tiny type or stripped whitespace. Long-form / art-directed statements (a poem broadside, a scroll-poster) may legitimately run taller, but even then the **first screen must read as a complete, deliberate composition** — never a headline sliced in half by the fold.
|
|
139
|
+
|
|
140
|
+
45. **Decorative-without-purpose.** Does the hero contain a decorative element (cursor, scanline, gradient blob, abstract shape, ornament, badge, sticker) that has no semantic anchor in the content? Fail. Decoration must be motivated: a cursor inside a typed command (signals "you'd type next"), a numeral that names an issue / year / version / chapter, a gradient that responds to interaction (HP3 cursor-spotlight), a stamp that names an authorship or date. Random ornaments — a "42" in the corner with no edition meaning, a cursor floating beside a hero, a Pantone chip with no colour rationale — are slop.
|
|
141
|
+
|
|
142
|
+
The `[arka:design-dna]` stamp should record the result alongside contrast: `nav=N# footer=Ft# slop=pass(42–45)`. If any of 42–45 fail, fix before shipping.
|
|
143
|
+
|
|
144
|
+
## Honest copy · no fabricated content
|
|
145
|
+
|
|
146
|
+
Universal — apply to every genre. The page must not invent facts about the user's product, team, or market.
|
|
147
|
+
|
|
148
|
+
46. **Invented metric.** Does the page contain any quantitative claim — "10× faster", "saves 5 hours per week", "trusted by 50,000+ teams", "99.9 % uptime", "+47 % conversion" — that the user did not supply, that has no source, and that the model fabricated to fill a stat-led layout, comparison row, or proof bar? If yes, fail. The fix is one of: replace the number with `—` and a labelled grey block, replace it with a question to the user ("metric to confirm"), or rebuild the section without the proof slot. Stat-led macrostructures are slop the moment their stats become decorative. **A stat is also never the hero's *sole* headline** — a lead figure carries the hero only alongside a worded headline; a giant number with no words as the dominant hero text is a bare-number tell, so pair it with a line that says what it means. *(See [anti-patterns.md § Invented metrics](anti-patterns.md).)*
|
|
149
|
+
|
|
150
|
+
## Re-drawn UI chrome
|
|
151
|
+
|
|
152
|
+
Universal. The ArkaOS design flow must reuse the user's existing chrome (browser, OS, IDE) instead of redrawing it.
|
|
153
|
+
|
|
154
|
+
47. **Re-drawn chrome.** Did the ArkaOS design flow hand-build a fake browser bar (URL pill + traffic-light dots), a fake phone frame (rounded rectangle + notch + speaker slit), a fake code-block frame (mock window-chrome around a `<pre>`), a fake terminal frame, or a fake IDE chrome (file tabs + activity bar + sidebar) using HTML/CSS or SVG? If yes, fail. Re-drawn chrome is one of the strongest "looks AI-generated" tells — the model invented a UI that already exists in the user's environment. The fix: use a `<picture>` or `<figure>` containing a real screenshot, or omit the chrome and let the content stand on its own. *(See [anti-patterns.md § Re-drawn UI chrome](anti-patterns.md).)*
|
|
155
|
+
|
|
156
|
+
## Token discipline
|
|
157
|
+
|
|
158
|
+
Universal. The theme picks the palette and font stack at the top of the run; the rest of the run consumes tokens, never invents them.
|
|
159
|
+
|
|
160
|
+
48. **Mid-render token improvisation.** Did the ArkaOS design flow introduce any colour value (`#hex`, `oklch(...)`, `rgb(...)`, `hsl(...)`) or `font-family` declaration *outside* the design tokens defined in `:root` / `[data-theme="..."]`? If yes, fail. Every colour and every font in the artifact must reference a named token (`var(--color-accent)`, `font-family: var(--font-display)`). Inline OKLCH or one-off hexes are mid-render improvisation — the model picked the theme, then forgot it and freestyled. The fix: lift the value into the token block as a new named variable, or replace it with an existing token. *(See the project token discipline — squad reference §3 — and [anti-patterns.md § Mid-render token improvisation](anti-patterns.md).)*
|
|
161
|
+
|
|
162
|
+
## Responsive — clickable affordances
|
|
163
|
+
|
|
164
|
+
Universal. Buttons, links, and nav items must remain readable as single-line affordances when the viewport shrinks.
|
|
165
|
+
|
|
166
|
+
49. **Two-line clickable text.** Does any button label, primary nav link, footer link, tab label, breadcrumb, or CTA text wrap to two or more lines at any viewport between 320 px and 1920 px? If yes, fail. Clickable text reading on two lines looks broken — visitors read it as a styling error, not as intentional. The fix is one of: shorten the label (the best fix; "Get started free" → "Start free"), set `white-space: nowrap` on the affordance and let the parent reflow, drop a non-essential nav item at narrow widths via `hidden=until-found`, or collapse the nav into a sheet/menu. Never let a CTA or nav link wrap. *(See `responsive.md` § Clickable text — never wraps.)*
|
|
167
|
+
|
|
168
|
+
The `[arka:design-dna]` stamp should record results: `honest=pass(46) chrome=pass(47) tokens=pass(48) responsive=pass(49) icons=pass(30)`. Any failure must be fixed before shipping.
|
|
169
|
+
|
|
170
|
+
## Mobile-responsiveness — the non-negotiables
|
|
171
|
+
|
|
172
|
+
Universal. Every emitted page must render flawlessly at 320 px, 375 px, 414 px, and 768 px CSS-pixel widths. Gates 34 (no horizontal scroll) and 49 (no two-line clickable text) already cover the headline cases; 50–57 below codify the patterns the marketing-site responsiveness pass uncovered. Eyeball each viewport before marking the output complete.
|
|
173
|
+
|
|
174
|
+
50. **Image-bearing grid track without `minmax(0, 1fr)`.** Does any `grid-template-columns` (or `grid-template-rows`) containing a `1fr` track render an `<img>` / `<picture>` / image-bearing element inside one of those tracks? If yes, the track must be `minmax(0, 1fr)` instead. Plain `1fr` resolves to `minmax(auto, 1fr)`, where `auto` minimum is the largest content's intrinsic width — for a 1024 + px native image, that's 1024 + px minimum, which pushes the layout past viewport on phones. The fix is one character per track: `1fr` → `minmax(0, 1fr)`.
|
|
175
|
+
|
|
176
|
+
51. **Display headers without long-word wrap.** Does any element rendering display-size text (`h1`, `.hero__display`, `.section__title`, `.skill-row__title`, hero-equivalent classes) lack `overflow-wrap: anywhere; min-width: 0`? If yes, fail. Long hyphenated words ("AI-generated", uppercase compound brand names) overflow viewport because the only break opportunity is at the hyphen — `overflow-wrap: anywhere` lets the engine break inside the word as a last resort.
|
|
177
|
+
|
|
178
|
+
52. **Per-theme section-head override without mobile collapse.** When a theme or variant overrides `.section__head { grid-template-columns: ... }` to anything other than `1fr`, does it also include the mobile-collapse rule, OR does a global `[data-theme] .section__head { grid-template-columns: 1fr }` exist at `@media (max-width: 48rem)` with matching specificity? If neither, fail. Theme-specific 2-column heads keep their template on mobile, the title wraps onto the section label, and the page reads broken (most visible on Sport: italic Anton title overlapping "02 / EXAMPLES").
|
|
179
|
+
|
|
180
|
+
53. **CSS-only radio tab pattern that scroll-jumps.** When implementing tab toggles via `<input type="radio">` siblings + `:checked` selectors, does the artifact either (a) keep the radios in normal document flow with zero size + opacity 0 (no `position: absolute; top: 0`), OR (b) ship a JS handler that intercepts label clicks, calls `e.preventDefault()`, manually sets `radio.checked = true`, dispatches `change`, and focuses with `{ preventScroll: true }`? If the radios are at `position: absolute; top: 0` with no JS guard, fail. Default-position radios cause the page to jump to the section's top on every tab click — visible on every viewport but most disruptive on mobile.
|
|
181
|
+
|
|
182
|
+
54. **Section eyebrow / tag beside the heading (tag-left, header-right).** Does any section render an eyebrow / number / mono-cap label (`01 · THE TOUR`, `02 / FEATURES`, `Chapter Three`) in a column to the left of, or to the right of, the section heading on the same horizontal row? Auto-fail. The pattern reads as a templated editorial-SaaS tell within seconds. When an eyebrow is used at all (see [`anti-patterns.md` § Eyebrow on every section](anti-patterns.md) — default OFF), the heading goes **directly underneath it in the same column**, vertical stack only. Concretely: **any `<header>`, `<div>`, or `<section>` wrapper — regardless of class name (`.section__head`, `.workbench__head`, `.pricing__head`, `.catches__head`, `.foo__intro`, anything macrostructure- or section-specific)** — that contains both an eyebrow / label / number / kicker element AND a heading element MUST resolve to single-column layout: `display: block`, `display: flex; flex-direction: column`, or `display: grid; grid-template-columns: 1fr` (or `minmax(0, 1fr)`). Any multi-column grid on such a wrapper (`grid-template-columns: 1fr 2fr`, `minmax(0, 0.4fr) minmax(0, 1fr)`, `auto 1fr`, etc.) is banned. **The rule binds on the *content shape* — eyebrow + heading in the same wrapper — not on a specific class-name allowlist.** It supersedes the "Left-margin" axis in `structure.md` and the "Hanging headers" pattern in `layout-and-space.md` for any head that carries an eyebrow. **NOT bypassable by "preserve structural parity" / "mirror this reference" / "match the prior build" instructions** — if a reference build ships the banned pattern (most pre-rule builds do), silently flatten it in the new build. The rules win over parity. Reference builds may pre-date this gate; the gate is authoritative.
|
|
183
|
+
|
|
184
|
+
55. **All-caps display heads with line-height < 1.0 → cap-collision on wrap.** Does any display-size element (`.hero__display`, `.section__title`, `h1`, `h2`, or anything `≥ --text-2xl`) declare both `text-transform: uppercase` AND a `line-height` (or `--lh-tight`) below `1.0`? If yes, fail. Uppercase glyphs have no descenders and their cap-tops sit at the very top of the line box — at `line-height: 0.94` (the old Manifesto / Sport / Brutal default) the cap-tops of line N+1 visibly collide with the baseline or commas of line N when the title wraps. The condensed display faces (Anton, Inter Tight 900, Bebas Neue) make this worse. **Floor for all-caps display heads is `line-height: 1.0`; recommended `1.02–1.08`.** Either bump `--lh-tight` ≥ 1.0 for the theme, or drop `text-transform: uppercase` on the display element. Most visible when a two-line `.section__title` wraps with a trailing comma on line one ("SAME PROMPT, TWO / DIFFERENT OUTPUTS.") — the comma + cap-D fuse into a single glyph blob.
|
|
185
|
+
|
|
186
|
+
56. **Sticky element at `top: 0` below a sticky page-level nav → bleed.** Does the artifact declare `position: sticky; top: 0;` on any element OTHER than the page's top-level nav / banner / header, when a sticky `<header>` / `<nav>` / `.banner` also exists at `top: 0` (i.e. there are two sticky-at-top-0 elements on the page)? Auto-fail. Both stick to the viewport top during scroll and overlap; the deeper-in-DOM element paints over the nav (visible as a "section header bleeding into the nav bar" glitch). Fix: define a `--banner-height` token (~44–64 px depending on nav design) and offset every secondary sticky to `top: var(--banner-height)`, so it docks **beneath** the nav. Also give the nav a higher z-index than in-page sticky elements — split `--z-sticky` (in-page, e.g. 200) from `--z-sticky-nav` (top nav, e.g. 300) so the nav always out-paints when sticky boxes momentarily overlap. This gate fires only when the page actually has sticky elements (S3 sticky-pinned section heads, F2 sticky-scroll feature stacks, sticky tables-of-contents); pages without sticky behaviour pass trivially.
|
|
187
|
+
|
|
188
|
+
57. **Studied DNA discarded for a catalog theme.** Did a `study` diagnosis emit earlier in the conversation, AND does the build's CSS stamp's `theme=` field name a catalog theme (Specimen, Midnight, Brutal, Garden, Atelier, Newsprint, Terminal, Manifesto, Almanac, Sport, Studio, Riso, Bloom, Coral, Cobalt, Aurora, Editorial, Carnival, Lumen, Hum) rather than `studied-DNA (source: ...)` — without the user having explicitly pivoted ("use Newsprint instead", "ignore the DNA", "rotate to a different theme")? Auto-fail. The studied DNA was meant to be the system; defaulting back to catalog is the attractor pull. Fix: re-emit using the studied DNA's tokens directly (paper OKLCH, accent OKLCH, named candidate fonts, macrostructure, archetypes) and update the stamp to `theme=studied-DNA (source: <URL or image>)` with the inline values. This gate is trivially passed when no recent study exists in conversation scope.
|
|
189
|
+
|
|
190
|
+
The `[arka:design-dna]` stamp records mobile pass alongside contrast: `mobile=pass(34,49,50–57)`.
|
|
191
|
+
|
|
192
|
+
---
|
|
193
|
+
|
|
194
|
+
If any answer is **yes**, fix it. Do not ship slop.
|
|
@@ -10,6 +10,10 @@ description: >
|
|
|
10
10
|
brand/design-review; slow pages or Core Web Vitals -> dev/performance-audit;
|
|
11
11
|
brand strength, not interface -> brand/primal-audit.
|
|
12
12
|
allowed-tools: [Read, Write, Edit, Bash, Grep, Glob, Agent, WebFetch, WebSearch]
|
|
13
|
+
metadata:
|
|
14
|
+
origin: community
|
|
15
|
+
source: https://github.com/nutlope/hallmark
|
|
16
|
+
license: MIT
|
|
13
17
|
---
|
|
14
18
|
|
|
15
19
|
<!-- arka:kb-first-prefix begin -->
|
|
@@ -35,6 +39,11 @@ Do this BEFORE auditing, in this order, and record what actually loaded:
|
|
|
35
39
|
that reads as AI-default gets flagged under aesthetic integrity).
|
|
36
40
|
3. **Read the project design system** — findings that violate the
|
|
37
41
|
project's own tokens rank higher than generic advice.
|
|
42
|
+
4. **Load the audit references** —
|
|
43
|
+
`../design-review/references/anti-patterns.md` (the named-tell
|
|
44
|
+
dictionary: every AI-slop finding is cited by its named entry and
|
|
45
|
+
Critical/Major/Minor tier) and `../design-review/references/slop-test.md`
|
|
46
|
+
(the 58 mechanical gates; run them on the audited surfaces).
|
|
38
47
|
|
|
39
48
|
### Graceful degradation (honest, never silent)
|
|
40
49
|
|
|
@@ -80,18 +89,30 @@ benchmark contrast, concrete fix.
|
|
|
80
89
|
|
|
81
90
|
## Workflow
|
|
82
91
|
|
|
92
|
+
0. **Pre-flight scan (read-only)** — before judging anything, read what
|
|
93
|
+
exists: tokens/theme files, font loads, framework, and the
|
|
94
|
+
`[arka:design-dna]` stamp in produced CSS when present. The audit
|
|
95
|
+
holds the surface to its OWN declared system first, the canonical
|
|
96
|
+
laws second. **The audit never edits** — it documents and ranks;
|
|
97
|
+
fixes belong to the owning build skill.
|
|
83
98
|
1. **Scope** — the 2–3 flows that carry the product's core job
|
|
84
99
|
(onboarding, core action, checkout/conversion).
|
|
85
100
|
2. **Walk the flows in a real browser** (steps below), capturing
|
|
86
101
|
evidence screenshots per finding.
|
|
87
102
|
3. **Score** every screen against the checklist; log findings as you go
|
|
88
103
|
— no memory-based auditing.
|
|
89
|
-
4. **
|
|
104
|
+
4. **Slop pass** — run the 58 gates (`slop-test.md`) and name every hit
|
|
105
|
+
from `anti-patterns.md`; check reflex-reject violations against the
|
|
106
|
+
squad reference §11 and design-law breaches against §12.
|
|
107
|
+
5. **Accessibility pass** — keyboard-only run, focus visibility,
|
|
90
108
|
contrast (AA), `prefers-reduced-motion`, semantic landmarks.
|
|
91
|
-
|
|
109
|
+
6. **Responsive pass** — 390 / 768 / 1440; layout integrity, target
|
|
92
110
|
sizes, content parity.
|
|
93
|
-
|
|
94
|
-
each with its fix and benchmark contrast.
|
|
111
|
+
7. **Report** — findings ranked by severity, quick-wins vs structural,
|
|
112
|
+
each with its fix and benchmark contrast. Header line:
|
|
113
|
+
`Summary — N critical · M major · K minor`; close with the verdict
|
|
114
|
+
line `Verdict — [ships as slop | reads as AI-generated | close, fix
|
|
115
|
+
the minors | clean]`.
|
|
95
116
|
|
|
96
117
|
## Browser Steps
|
|
97
118
|
|
|
@@ -64,6 +64,8 @@ expertise:
|
|
|
64
64
|
- CWV Optimization
|
|
65
65
|
- ArkaOS Motion System
|
|
66
66
|
- Design Tokens (DTCG)
|
|
67
|
+
- Hallmark slop gates (58) + pre-emit critique (P/H/E/S/R/V)
|
|
68
|
+
- Impeccable design laws + registers (brand vs product)
|
|
67
69
|
- runtime:frontend-design (Anthropic skill)
|
|
68
70
|
- runtime:ui-ux-pro-max (community skill)
|
|
69
71
|
depth: expert
|
package/harness/codex/AGENTS.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# ArkaOS — The Operating System for AI Agent Teams
|
|
2
2
|
|
|
3
|
-
> v4.
|
|
3
|
+
> v4.29.0 — 89 agents, 17 departments, 329 skills. Generated by `scripts/harness_gen.py`; do not edit.
|
|
4
4
|
|
|
5
5
|
You are operating within ArkaOS. Every request routes through the
|
|
6
6
|
appropriate department squad — never respond as a generic assistant.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# ArkaOS — The Operating System for AI Agent Teams
|
|
2
2
|
|
|
3
|
-
> v4.
|
|
3
|
+
> v4.29.0 — 89 agents, 17 departments, 329 skills. Generated by `scripts/harness_gen.py`; do not edit.
|
|
4
4
|
|
|
5
5
|
You are operating within ArkaOS. Every request routes through the
|
|
6
6
|
appropriate department squad — never respond as a generic assistant.
|
|
@@ -1,11 +1,11 @@
|
|
|
1
1
|
---
|
|
2
|
-
description: ArkaOS v4.
|
|
2
|
+
description: ArkaOS v4.29.0 agent-team contract
|
|
3
3
|
alwaysApply: true
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# ArkaOS — The Operating System for AI Agent Teams
|
|
7
7
|
|
|
8
|
-
> v4.
|
|
8
|
+
> v4.29.0 — 89 agents, 17 departments, 329 skills. Generated by `scripts/harness_gen.py`; do not edit.
|
|
9
9
|
|
|
10
10
|
You are operating within ArkaOS. Every request routes through the
|
|
11
11
|
appropriate department squad — never respond as a generic assistant.
|
package/harness/gemini/GEMINI.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# ArkaOS — The Operating System for AI Agent Teams
|
|
2
2
|
|
|
3
|
-
> v4.
|
|
3
|
+
> v4.29.0 — 89 agents, 17 departments, 329 skills. Generated by `scripts/harness_gen.py`; do not edit.
|
|
4
4
|
|
|
5
5
|
You are operating within ArkaOS. Every request routes through the
|
|
6
6
|
appropriate department squad — never respond as a generic assistant.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# ArkaOS — The Operating System for AI Agent Teams
|
|
2
2
|
|
|
3
|
-
> v4.
|
|
3
|
+
> v4.29.0 — 89 agents, 17 departments, 329 skills. Generated by `scripts/harness_gen.py`; do not edit.
|
|
4
4
|
|
|
5
5
|
You are operating within ArkaOS. Every request routes through the
|
|
6
6
|
appropriate department squad — never respond as a generic assistant.
|
package/harness/zed/.rules
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# ArkaOS — The Operating System for AI Agent Teams
|
|
2
2
|
|
|
3
|
-
> v4.
|
|
3
|
+
> v4.29.0 — 89 agents, 17 departments, 329 skills. Generated by `scripts/harness_gen.py`; do not edit.
|
|
4
4
|
|
|
5
5
|
You are operating within ArkaOS. Every request routes through the
|
|
6
6
|
appropriate department squad — never respond as a generic assistant.
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"_meta": {
|
|
3
3
|
"version": "2.0.0",
|
|
4
|
-
"generated": "2026-07-
|
|
4
|
+
"generated": "2026-07-21T22:29:49.522966",
|
|
5
5
|
"total_agents": 89,
|
|
6
6
|
"generator": "core/agents/registry_gen.py",
|
|
7
7
|
"tiers": {
|
|
@@ -87,7 +87,9 @@
|
|
|
87
87
|
"Atomic Design (Frost)",
|
|
88
88
|
"Nielsen Heuristics",
|
|
89
89
|
"Dieter Rams 10 Principles",
|
|
90
|
-
"Double Diamond"
|
|
90
|
+
"Double Diamond",
|
|
91
|
+
"Hallmark slop gates (58) + pre-emit critique (P/H/E/S/R/V)",
|
|
92
|
+
"Impeccable design laws + registers (brand vs product)"
|
|
91
93
|
],
|
|
92
94
|
"knowledge_sources": [],
|
|
93
95
|
"file": "departments/brand/agents/brand-director.yaml",
|
|
@@ -192,7 +194,9 @@
|
|
|
192
194
|
"WCAG 2.2",
|
|
193
195
|
"Style Dictionary",
|
|
194
196
|
"shadcn/ui conventions",
|
|
195
|
-
"Tailwind CSS configuration"
|
|
197
|
+
"Tailwind CSS configuration",
|
|
198
|
+
"Hallmark slop gates (58) + pre-emit critique (P/H/E/S/R/V)",
|
|
199
|
+
"Impeccable design laws + registers (brand vs product)"
|
|
196
200
|
],
|
|
197
201
|
"knowledge_sources": [],
|
|
198
202
|
"file": "departments/brand/agents/design-ops/design-ops-lead.yaml",
|
|
@@ -346,7 +350,9 @@
|
|
|
346
350
|
"ATAG 2.0",
|
|
347
351
|
"EAA / EN 301 549",
|
|
348
352
|
"axe-core ruleset",
|
|
349
|
-
"Section 508"
|
|
353
|
+
"Section 508",
|
|
354
|
+
"Hallmark slop gates (58) + pre-emit critique (P/H/E/S/R/V)",
|
|
355
|
+
"Impeccable design laws + registers (brand vs product)"
|
|
350
356
|
],
|
|
351
357
|
"knowledge_sources": [],
|
|
352
358
|
"file": "departments/brand/agents/design-ops/wcag-auditor.yaml",
|
|
@@ -410,6 +416,8 @@
|
|
|
410
416
|
"WCAG 2.1 AA",
|
|
411
417
|
"Two-Part Conversion Formula",
|
|
412
418
|
"Microinteractions (trigger-rules-feedback-loops)",
|
|
419
|
+
"Hallmark slop gates (58) + pre-emit critique (P/H/E/S/R/V)",
|
|
420
|
+
"Impeccable design laws + registers (brand vs product)",
|
|
413
421
|
"runtime:frontend-design (Anthropic skill)"
|
|
414
422
|
],
|
|
415
423
|
"knowledge_sources": [
|
|
@@ -516,7 +524,9 @@
|
|
|
516
524
|
"4 Elements of UX Strategy (Levy)",
|
|
517
525
|
"Blue Ocean / Value Innovation",
|
|
518
526
|
"Provisional Personas",
|
|
519
|
-
"Lean UX"
|
|
527
|
+
"Lean UX",
|
|
528
|
+
"Hallmark slop gates (58) + pre-emit critique (P/H/E/S/R/V)",
|
|
529
|
+
"Impeccable design laws + registers (brand vs product)"
|
|
520
530
|
],
|
|
521
531
|
"knowledge_sources": [
|
|
522
532
|
"[[Personas/Jaime Levy]]",
|
|
@@ -574,6 +584,8 @@
|
|
|
574
584
|
"Brand Identity Process (Wheeler)",
|
|
575
585
|
"ArkaOS Design Tokens",
|
|
576
586
|
"WCAG AA contrast",
|
|
587
|
+
"Hallmark slop gates (58) + pre-emit critique (P/H/E/S/R/V)",
|
|
588
|
+
"Impeccable design laws + registers (brand vs product)",
|
|
577
589
|
"runtime:frontend-design (Anthropic skill)",
|
|
578
590
|
"runtime:ui-ux-pro-max (community skill)"
|
|
579
591
|
],
|
|
@@ -1748,6 +1760,8 @@
|
|
|
1748
1760
|
"CWV Optimization",
|
|
1749
1761
|
"ArkaOS Motion System",
|
|
1750
1762
|
"Design Tokens (DTCG)",
|
|
1763
|
+
"Hallmark slop gates (58) + pre-emit critique (P/H/E/S/R/V)",
|
|
1764
|
+
"Impeccable design laws + registers (brand vs product)",
|
|
1751
1765
|
"runtime:frontend-design (Anthropic skill)",
|
|
1752
1766
|
"runtime:ui-ux-pro-max (community skill)"
|
|
1753
1767
|
],
|