READYPLAY Design DNA Handbook
The full READYPLAY how-to book for moving from operator intent through structure, state, Suit work, proof, and shared learning.
READYPLAY Design DNA Handbook
i · Cover
A full how-to guide for building READYPLAY from first intent to live proof
Design DNA is the shared memory for how READYPLAY should work, read, move, and feel. It turns the operator's design judgment into clear rules a new builder can follow without the old chat.
Intent + Structure + State + Proof = Trusted Experience
ii · Intent and purpose
This book has one job: help a builder make a READYPLAY experience that is calm, clear, useful, and true.
It joins product meaning, page shape, type, color, motion, input, state, accessibility, CMS content, Suit adaptation, and release proof. It says who owns each kind of truth. It also says what to do when data or proof is missing.
This is a how-to guide. It does not ask a builder to guess what “premium” or “modern” means. It gives named parts, stable IDs, size rules, state rules, events, safe ways back, tests, and source paths.
The goal is not to make every READYPLAY screen look the same. The goal is to make every screen feel like the same careful family while it serves its own job.
iii · Short summary
Start with the human job. Name the next useful action, the active scope, the owner, and the proof boundary. Then separate the engine from its shell and skin. Pick the right human record shape. Name each useful part. Build every real state. Use the shared grid, type, color, and motion rules. Give pointer, touch, keyboard, phone, Light, Dark, and Reduced Motion the same meaning. Prove the real host. Record what was learned so the next build starts better.
The full build order is:
Operator intent
→ Semantic Node / Egg
→ Feature Control Record
→ Settings door
→ Job + next action + scope + proof
→ Fruit / Skeleton / Skin and Motion
→ Human record shape + stable nodes
→ States + inputs + safe way back
→ Suit build
→ Source, runtime, and visual proof
→ Recap, Review, Learn, Improve, Propagate
iv · Table of contents
Front matter
- i · Cover
- ii · Intent and purpose
- iii · Short summary
- iv · Table of contents
- v · How to read this handbook
- vi · The Design DNA build map
Part I · Meaning before form
- §01 · Start with the job — What is this screen helping a person do?
- §02 · Keep truth with its owner — Which system may decide each fact?
- §03 · Build fruit before skin — What must survive every visual change?
Part II · Shape the experience
- §04 · Pick the human record shape — What should the person see first?
- §05 · Use the nested snap grid — How do parts fit, move, and resize?
- §06 · Make type and numbers one family — How does the page stay easy to scan?
- §07 · Give color a clear job — What does each READYPLAY color mean?
- §08 · Make Light and Dark whole — Does the full hierarchy survive both modes?
Part III · Make action clear
- §09 · Let motion explain change — Can the person see what moved and why?
- §10 · Give every input equal power — Can touch, pointer, and keys finish the job?
- §11 · Build honest states and a safe way back — What happens when truth is late or missing?
Part IV · Publish, prove, and teach
- §12 · Join CMS, ACT, and the Suits — Which layer owns words, display, and action?
- §13 · Prove the real host — What evidence is enough to ship?
- §14 · Return the lesson to Design DNA — How does one fix improve the next build?
Back matter
- vii · Sources and authority map
v · How to read this handbook
Read the book from start to finish for a new product. Open one chapter when you are fixing a known problem. Use the table of contents as the stable map.
Each numbered chapter has five bands:
- Job — the human need and owner;
- Law — the rule that must stay true;
- Build — the order and named parts;
- Check — the proof needed before release; and
- Carry Forward — the lesson that belongs in future work.
The words must and may not mark a release rule. A code path, route, ID, version, or command is kept exact. A proposed color meaning or future feature is clearly marked as proposed.
Status words stay exact:
- Built means source or an artifact exists.
- Observed means the named behavior ran in the named place.
- Proven means the stated checks passed with saved evidence.
- Commissioned means the owner accepted the system for real use.
- Unknown means the answer still needs a check.
One status never stands in for another.
vi · The Design DNA build map
| Stage | Main question | Output | Stop if |
|---|---|---|---|
| Intent | What did the operator ask for? | faithful source note | the meaning is still unclear |
| Authority | Who owns each truth and write? | owner map | two systems claim the same fact |
| Fruit | What must the feature do? | inputs, outputs, rules, effects | the function is hidden in the skin |
| Skeleton | What order and shape teach the job? | regions, grid, reading path | raw fields decide the page |
| Skin | Which type, color, depth, and motion support it? | named tokens | decoration changes meaning |
| States | What happens before, during, after, and on failure? | state map and safe return | an empty or error state lies |
| Suit | How does the native host express the same meaning? | target build | shared meaning is copied by guess |
| Proof | What did source, runtime, and the live host show? | dated receipts | a build result is called live proof |
| Learning | What should start better next time? | DNA update and backfill | the lesson stays in chat |
┌─────────────── Design DNA ───────────────┐
│ shared meaning, form law, and proof gate │
└──────────────────┬───────────────────────┘
│
┌────────────────────┼────────────────────┐
│ │ │
READYPLAY Core CMS by Nephew One Each Suit
product contracts approved book words native body
│ │ │
└────────────────────┼────────────────────┘
│
READYPLAY ACT reader
inspection, settings, and proof
§01 · Start with the job
Job
Name what the person came to do. Name the next useful action. Name the active scope. Name what the screen can and cannot prove.
Law
Composition comes before decoration. A page is not a group of cards. It is a guided answer to one human job.
Build
Write four lines before component work:
Job:
Next action:
Active scope:
Proof boundary:
Choose one main canvas. Keep its first useful action easy to see. Put support work near the edge or behind a clear door.
Check
Ask a new person to name the page job and next action in ten seconds. If they cannot, fix the order before color or motion.
Carry Forward
Do not begin with a component library. Begin with the reason the screen exists.
§02 · Keep truth with its owner
Job
Make every fact, write, setting, and proof traceable to the system allowed to own it.
Law
READYPLAY API and PostgreSQL own operational truth. CMS by Nephew One owns approved content and publishing truth. READYPLAY Core owns shared product contracts. Design DNA owns presentation meaning. Each Suit owns its native renderer and proof.
Build
For each value, name its owner, reader, writer, source key, revision rule, and failure state. A projection may show a fact. It may not become a second owner.
Check
Turn one source off. The screen must say unavailable or use a named safe fallback. It must not guess, copy stale truth without a label, or open a hidden write path.
Carry Forward
A clean authority boundary makes both the interface and the code easier to trust.
§03 · Build fruit before skin
Job
Keep the useful engine safe while its body changes across web, Swift, Electron, WordPress Theme, Unity, Unreal Engine, Tizen, or another Suit.
Law
Fruit is capability, state, data, permission, side effect, and proof. Skeleton is region, order, size, and responsive shape. Skin and Motion are type, color, border, depth, and movement. A skin change may not delete fruit.
Build
Hatch one Semantic Node, also called an Egg. Freeze its thick-side function. Put allowed display choices on its thin side. Search the Gift Egg catalog before making a new part. Reuse by contract and pointer, not blind copy.
Check
Make a protected-capability list before the visual change. Test every item after. A polished screen with one missing permission, state, or action fails.
Carry Forward
The engine can stay stable while each Suit gets clothes that fit its host.
§04 · Pick the human record shape
Job
Turn source data into the order a person needs to read it.
Law
The database shape is not the page shape. A person, game, achievement, receipt, article, setting, and system node each need a different reading order.
Build
Name the record type. Put identity and meaning first. Put the main value and state next. Put the next action near it. Move machine IDs, hashes, and raw proof into a disclosed evidence area unless exact comparison is the main job.
Check
Use the longest real label, two similar records, missing optional data, and a long machine value. The person must still know what the record is and what to do.
Carry Forward
Choose the human story before choosing table, card, chart, list, or sheet.
§05 · Use the nested snap grid
Job
Make parts line up, resize, and move in a way the eye can follow.
Law
Use 4 points for fine work, 8 points for common space, 32 points for major structure, and 32 logical columns for builder canvases. Each movable part names its minimum, preferred, and maximum span.
Build
Use one shared movable-board part when two pages need the same move behavior. Keep the full card visible in the hand. Slide nearby cards into preview places before saving. Store a presentation choice separately from product data.
Check
Test pointer drag, touch when supported, Arrow keys, phone move buttons, cancel, reset, reload, and Reduced Motion. A dragged item may not vanish.
Carry Forward
Direct movement must show cause and result. Reuse one tested motion owner.
§06 · Make type and numbers one family
Job
Let a person scan names, facts, and key numbers without meeting a new type style in every card.
Law
Use display type for page statements, body type for reading, and mono type with tabular numbers for measures, scores, IDs, and time. Weight shows importance; it is not the only way to create hierarchy.
Build
Keep one type scale. Use short uppercase labels with careful spacing. Use strong but not always black number weight. Put key numbers in quiet one-pixel boxes with shared padding, radius, and baseline. Use the same recipe on the Player Exchange and other metric pages.
Check
Compare 8, 88, 634, 1,202, a negative value, a missing value, and a long
name. The number boxes must line up and the labels must remain clear in Light
and Dark.
Carry Forward
Type is structure. Fix the shared token or recipe instead of polishing each number by hand.
§07 · Give color a clear job
Job
Use color to show identity, state, or action without making color the only clue.
Law
The filled red rounded square is the READYPLAY product mark. Ready Red is the only canonical state meaning today. Blue Chipper, Go Green, Caution Yellow, Heat Orange, Reset White, and Streak Black are proposed. Every palette face has Standard, Glow, and Dim strength.
Build
Keep the face simple. Caution Yellow and Reset White have no dark inner square. Streak Black keeps a red E as a second clue. Add a word, icon, shape, or pattern for every live state so color is never the only meaning. Glow is emphasis. Dim is context. Neither changes the state itself.
Check
Test every face on Light and Dark, with color-vision checks and Reduced Motion. Do not connect a proposed meaning to live player data without its own approved rule, source, label, and receipt.
Carry Forward
Color and meaning are separate contracts. Change one without quietly changing the other.
§08 · Make Light and Dark whole
Job
Keep the same reading order and meaning in two complete appearances.
Law
Light is a daylight work space. Dark is an ink work space. A fixed dark hero or command frame inside Light is not adaptive.
Build
Give the root, hero, card, chip, border, hover, focus, error, chart, and empty state an explicit recipe for both modes. Brand red stays identity. White glow and glass are Dark treatments unless a Light recipe has proof.
Check
Review the component root, not only the page background. Test contrast, focus, screenshots, charts, and overlays in both modes.
Carry Forward
Appearance is a full hierarchy change, not a background switch.
§09 · Let motion explain change
Job
Help the eye understand where an item came from, where it went, and which state changed.
Law
Direct motion is fast, clear, and tied to an action. Use about 180 to 260 milliseconds. Ambient motion may be slower. Reduced Motion removes travel and lift without hiding state.
Build
Keep the moved object visible. Animate nearby layout change. Save only after the move lands. Return to the old state on cancel. Use opacity alone only when location does not matter.
Check
Record a normal move, cancel, fast repeat, keyboard move, and Reduced Motion. The result must be clear without motion as well.
Carry Forward
Motion is an explanation layer. It may not become delay or decoration.
§10 · Give every input equal power
Job
Let a person finish the same work with pointer, touch, keyboard, and assistive tools.
Law
An input change may change the control shape. It may not remove the action. Targets are at least 44 points. Focus is visible. Escape closes temporary surfaces. Native controls and names come first.
Build
Pair drag with Arrow keys and phone move buttons. Pair hover with focus. Pair a gesture with a visible action. Keep fieldset and legend text when choices form one group.
Check
Finish the whole task with only a keyboard. Then finish it at phone width. Test large text, focus order, labels, Escape, and a screen reader.
Carry Forward
Access is part of the feature contract, not a cleanup pass.
§11 · Build honest states and a safe way back
Job
Keep the person informed and in control when data is late, missing, denied, or wrong.
Law
Zero, empty, unknown, unavailable, loading, error, restricted, disputed, and provisional are different states. A safe fallback may keep work moving. It may not hide stale or copied truth.
Build
Name all states that apply. Give each one plain words, a useful next action, and a safe return. Settings must have reset when the setting is local. A server rule stays read-only and names its owner.
Check
Force each state. Break one supporting feed while the main content still works. Reload a deep link. The page must keep its truth and a clear way home.
Carry Forward
Failure design is product design. Build it before the happy path is called done.
§12 · Join CMS, ACT, and the Suits
Job
Let approved words move through the publishing engine while each product keeps its own runtime and display authority.
Law
CMS by Nephew One owns approved book copy, revision, workflow, and publication. The WordPress Engine is the content engine. READYPLAY ACT owns this reading experience. Design DNA owns presentation. READYPLAY Core and PostgreSQL keep operational truth. No iframe, page-builder HTML, or copied business data may erase those lines.
Build
Publish the handbook to the rp-child-08 Design & Product System child. Bind it
to the stable slug readyplay-design-dna-handbook. ACT reads the published CMS
copy first. If CMS cannot answer, ACT shows the revisioned Git book and says it
is the fallback.
Check
Prove publish workflow, exact readback, child ID, slug, source path, revision, state, and fallback. CMS editing must not gain a hidden operational write.
Carry Forward
One book can have many readers. It still needs one named publishing owner.
§13 · Prove the real host
Job
Show that the intended experience works in the place the person will use it.
Law
Source proves declared code. A build proves an artifact. A runtime trace proves the path that ran. A screenshot proves the shown appearance. A live readback proves the named deployed result. None proves more than its own scope.
Build
Test the smallest set that covers the risk: source tests, build, Light, Dark, phone, desktop, shell modes, keyboard, Reduced Motion, empty, error, and live URL. Save exact revisions and receipts.
Check
Compare expected and actual. Keep any missed state open. Do not call the whole system proven because one screenshot looks right.
Carry Forward
Proof should make the next change safer, not only close the current task.
§14 · Return the lesson to Design DNA
Job
Make one operator correction improve future first drafts.
Law
Every substantive improvement ends with Recap, Review, Learn, Improve, and Propagate.
Build
Preserve the operator signal. Compare expected with actual. Name the root lesson and the better first build. Update Design DNA, Engineering DNA, the Design Desire Dossier, tests, proof, and bounded backfill. Make a Gift Egg only when the reusable contract and refusal cases are stable.
Check
A new builder must be able to repeat the work from the book and exact source paths without the old chat. A listed backfill is not called fixed until it has its own proof.
Carry Forward
The product family should not pay twice for the same lesson.
vii · Sources and authority map
| Source | Role |
|---|---|
packages/readyplay-core/contracts/design-dna.v1.json | shared Design DNA machine law |
packages/readyplay-core/contracts/design-dna-encyclopedia.v1.json | constitutional law and family registry |
packages/readyplay-core/contracts/engineering-dna.v1.json | build, failure, reuse, and proof law |
docs/design-dna/READYPLAY-DESIGN-DNA.md | living presentation doctrine |
docs/design-dna/DESIGN-DNA-ENCYCLOPEDIA.md | current rebuild records and audit state |
docs/design-dna/READYPLAY-BUILD-ETHICS.md | Settings First, Egg, grid, and Gift Egg build order |
docs/design-dna/READYPLAY-DESIGN-FUTURE.md | future review and proof gates |
docs/design-dna/READYPLAY-DESIGN-DESIRE-DOSSIER.md | append-only operator intent and lessons |
docs/design-dna/READYPLAY-INTERACTIVE-WIRING-STANDARD.md | connected-system display law |
docs/design-dna/READYPLAY-INTERACTIVE-WIRING-WHITE-PAPER.md | full wiring method |
docs/design-dna/*.design-culture.json | measured skins, shells, tokens, and references |
interface/web-admin/lib/design-dna.ts | ACT platform and component records |
interface/web-admin/lib/design-dna-encyclopedia.ts | typed ACT encyclopedia reader |
scripts/either-host/check-design-authority.mjs | source-level release refusal gate |
config/cms/readyplay.cms-network.json | CMS child, audience, authority, and projection map |
backend/scripts/publish-cms-doc-to-nephew-one.js | dry-run-safe CMS publication and readback |
docs/research/concise-perspective-design-dna-book-study.md | source study of the named book structure |
The Concise Perspective repository supplied the structural precedent at commit
542dbaeec116589ba7db4062a02f6febc71d0eb2. READYPLAY preserves the book rhythm
and makes its own original product-design content.
Release check
- The operator's intent is preserved.
- The job, next action, scope, owner, and proof boundary are clear.
- Fruit, Skeleton, Skin, and Motion are separate.
- Stable node IDs and all real states are named.
- Type, number, color, border, and grid rules use shared tokens.
- Light, Dark, phone, desktop, keyboard, touch, and Reduced Motion work.
- CMS publish and Git fallback show their source state.
- Source, runtime, visual, and live claims stay separate.
- The lesson returns to the Dossier, DNA, tests, and backfill map.