# Kiduna Studio Design-System Program

## Purpose

This pack establishes a disciplined way to design the inside of Kiduna Studio without turning the canonical taxonomy or the 172 known capabilities into 172 equally weighted screens.

The working hypothesis is:

> Kiduna Studio is the primary desktop/laptop Surface into the Field. Within it, a focused conversational workspace centers the active Realm and can reveal a broader Atlas orientation view when useful.

The Field is always the complete environment; it is not an optional map mode. The default Studio presentation should organize itself around one active Realm, one current intention, and one dominant conversation or piece of work. Elements, data, collaborators, tools, and operational detail appear when relevant and recede when they are not.

## Start in this order

1. Read [DESIGN_DIAGNOSIS.md](DESIGN_DIAGNOSIS.md).
2. Review the hypothesis in [STUDIO_DESIGN_SYSTEM_BRIEF.md](STUDIO_DESIGN_SYSTEM_BRIEF.md).
3. Review how an intelligent Realm works in [REALM_EXPERIENCE_MODEL.md](REALM_EXPERIENCE_MODEL.md).
4. Review the reusable UI language in [INTERACTION_PATTERN_LIBRARY.md](INTERACTION_PATTERN_LIBRARY.md).
5. Use [WORKING_PLAN.md](WORKING_PLAN.md) to conduct short design rounds.
6. Use [CAPABILITY_COVERAGE_STRATEGY.md](CAPABILITY_COVERAGE_STRATEGY.md) to prevent omissions without multiplying navigation.
7. Read [OPEN_DECISIONS.md](OPEN_DECISIONS.md) before treating any proposal as settled.
8. Record each gate decision in [DECISION_LOG.md](DECISION_LOG.md).

## What is decided

- The outside-the-Field visual language is the strongest current foundation.
- Conversation with Ki is the primary interaction model.
- The system must support Field orientation, Realm intelligence, Elements, contextual agents, actions, approvals, progress, and durable receipts.
- The user must be able to identify an Element, preview it, expand it, bring it into the main conversation, act on it, and recover its history.
- Connected systems should operate quietly until their data or controls are relevant.
- Consequential actions require visible authority and the appropriate human or governance gate.

## What is not decided

- Whether the default inside-Studio label is **Chat**, **Work**, or another term.
- The final spatial treatment of the Field.
- Whether expanded Elements use a side Lens, a central Stage, or both by scale.
- The final persistent navigation model.

The full consolidated Kiduna Core Taxonomy Version 1.3.3 is now the canonical source for all taxonomy sections. Version 1.3.2 is retained as its complete predecessor.

## Skills

The `skills/` directory contains four reusable agent skills:

- `design-kiduna-realm` — define the intelligence and experience of a Realm.
- `compose-kiduna-interaction` — turn a capability into a focused conversational interaction.
- `audit-kiduna-capabilities` — verify coverage without requiring a page per capability.
- `review-kiduna-studio` — critique hierarchy, clarity, vibe, trust, and completeness.

These are working skills. Validate them against the next design rounds before treating them as final engineering instructions.

The `references/` directory contains portable copies of the supplied capability catalog, repository snapshot register, inventory summary, high-level V1 audit documents, and complete canonical Taxonomy Versions 1.3.2 and 1.3.3. Version 1.3.3 is current; earlier versions remain historical evidence.

## Immediate next step

Gate 0 and Gate 1 are accepted. Gate 2A's definition artifacts are complete and awaiting owner review. Begin with [GATE_2A_REVIEW_INDEX.md](GATE_2A_REVIEW_INDEX.md), then review the shared collective-agency model, the three Realm contracts, the cross-Realm matrix, and the six Gate 2B scene briefs. Do not begin Gate 2B interface work until Gate 2A is accepted.

The completed activation instruction is retained in [GATE_2_ACTIVATION_PROMPT.md](GATE_2_ACTIVATION_PROMPT.md). The earlier [NEXT_PROMPT.md](NEXT_PROMPT.md) is retained as Gate 1 history.
