@jaimevalasek/aioson 1.5.1 → 1.6.0

package/template/.aioson/skills/process/aioson-spec-driven/SKILL.md

@@ -0,0 +1,45 @@
+# Skill: aioson-spec-driven
+
+> Process methodology skill. Covers: phase sequencing, artifact contracts, approval gates, and hardening lane.
+> Load this file first. Then load only the `references/` file relevant to your current role and phase.
+
+## When to use
+
+Load this skill when:
+- starting spec work for a new feature or project (any agent)
+- deciding phase depth based on classification (MICRO / SMALL / MEDIUM)
+- preparing a clean handoff to the next agent
+- retaking work after a session break (check `last_checkpoint` + `phase_gates` first)
+
+Do NOT load the entire `references/` folder. Load only the file matching your current need.
+
+## What phases exist
+
+| Phase | AIOSON artifact | Primary agent | MICRO | SMALL | MEDIUM |
+|-------|----------------|---------------|-------|-------|--------|
+| Specify | `prd*.md` | @product | lite | full | full |
+| Research/Discuss | `sheldon-enrichment*.md` | @sheldon | optional | recommended | required |
+| Requirements | `requirements-{slug}.md` | @analyst | skip | required | required |
+| Design | `architecture.md`, `design-doc*.md` | @architect | skip | selective | required |
+| Tasks/Plan | `implementation-plan*.md` | @dev | optional | recommended | required |
+| Execute | code, commits, spec updates | @dev, @deyvin | — | — | — |
+| State/Resume | `spec*.md`, runtime | @dev, @deyvin | — | — | — |
+
+## Phase depth by classification
+
+- **MICRO**: Specify (lite) + Execute. Skip Requirements, Design, Plan unless complexity warrants it.
+- **SMALL**: Specify + Requirements + selective Design + Plan. @sheldon recommended before downstream.
+- **MEDIUM**: Full pack — all phases, all artifacts, @sheldon validation before @analyst, implementation plan required.
+
+## References available
+
+Load the file that matches your current context — do not load all at once:
+
+| File | Load when |
+|------|-----------|
+| `references/artifact-map.md` | You need to know which artifact lives where and who owns it |
+| `references/classification-map.md` | You need to decide phase depth for a project or feature |
+| `references/approval-gates.md` | You are preparing a handoff and need to know what must be ready |
+| `references/hardening-lane.md` | The input is vague, exploratory, or "vibe-style" and needs to be converted |
+| `references/maintenance-and-state.md` | You are writing or reading `spec*.md`, checkpoints, or retaking work |
+| `references/ui-language.md` | You need to present options, status symbols, or checkpoints to the user with consistent visual standards |

package/template/.aioson/skills/process/aioson-spec-driven/references/approval-gates.md

@@ -0,0 +1,109 @@
+# Approval Gates — Spec-Driven Phase Transitions
+
+> Use when preparing a handoff or checking if a phase is ready to proceed.
+> Gates are blocking in MEDIUM. Informational in MICRO/SMALL.
+
+## Gate A — Requirements approval
+
+**Before leaving @product / @analyst → @architect or @dev**
+
+Required for the gate to pass:
+- [ ] Objectives are clear and unambiguous
+- [ ] Expected behaviors are described (not just features — what happens when X)
+- [ ] Constraints are explicit (what this version does NOT do)
+- [ ] Out of scope is listed
+- [ ] Open ambiguities are documented (not silently ignored)
+- [ ] Requirement IDs exist for all business rules: `REQ-{slug}-{N}`
+- [ ] Acceptance criteria exist for all behavioral requirements: `AC-{slug}-{N}`
+
+**Signal in `spec-{slug}.md`:** set `phase_gates.requirements: approved`
+
+**Not ready if:**
+- Requirements reference behavior that hasn't been decided
+- ACs are not independently verifiable (e.g., "works correctly" is not an AC)
+- There are contradictions between PRD and requirements
+
+---
+
+## Gate B — Design approval
+
+**Before leaving @architect → @dev**
+
+Required for the gate to pass:
+- [ ] Technical approach is chosen and documented
+- [ ] Module/folder structure is defined
+- [ ] Dependencies between components are explicit
+- [ ] Risks and non-goals are documented
+- [ ] Decision rationale exists for non-obvious choices
+- [ ] @dev can start without having to invent business logic or architecture
+
+**Signal in `spec-{slug}.md`:** set `phase_gates.design: approved`
+**Signal in `architecture.md`:** closing line `> **Gate B:** Architecture approved — @dev can proceed.`
+
+**Not ready if:**
+- There are open decisions that @dev would need to make up during implementation
+- The architecture introduces patterns not supported by the project's stack
+- There are circular dependencies in the module structure
+
+---
+
+## Gate C — Plan approval
+
+**Before @dev or @deyvin executes a significant batch**
+
+Required for the gate to pass:
+- [ ] Execution sequence is defined
+- [ ] Checkpoints are listed with criteria of done
+- [ ] Context package is listed (which files to read before each phase)
+- [ ] Review / QA requirements are noted
+- [ ] Decisions marked "pre-taken" are FINAL — @dev does not re-discuss
+
+**Signal in `spec-{slug}.md`:** set `phase_gates.plan: approved`
+**Signal in `implementation-plan-{slug}.md`:** status field = `approved`
+
+**Not ready if:**
+- The plan has phases with unclear done criteria
+- There are external dependencies not yet resolved
+- @dev would need to re-read the full spec from scratch to start
+
+---
+
+## Gate D — Execution verification (must_haves)
+
+**Before marking a phase or feature as complete**
+
+Required:
+- [ ] All truths verified (behavioral — not just "I think it works")
+- [ ] All artifacts verified (substantive — not stubs)
+- [ ] All key_links verified (wiring — imports, registrations, middleware)
+
+**Not complete if:**
+- Any truth has no passing test or manual verification step
+- Any artifact is empty, a stub, or missing required exports
+- Any key_link shows the code exists but isn't connected
+
+**Signal:** update `last_checkpoint` in `spec-{slug}.md` with which must_haves passed and which failed.
+
+---
+
+## Checkpoint taxonomy reference
+
+Quando qualquer agente precisa de interação humana durante execução:
+
+| Tipo | Quando | Frequência esperada |
+|------|--------|---------------------|
+| `verify` | Confirmar comportamento visível | Comum — após cada entrega testável |
+| `decision` | Bifurcação arquitetural ou de produto | Rara — apenas quando não especificado |
+| `action` | Passo que o agente não consegue executar | Muito rara — <1% dos steps |
+
+Regra: se o agente consegue executar sem risco, execute. Não peça confirmação desnecessária.
+
+---
+
+## How agents communicate gate status
+
+Each agent, at session end, should:
+1. Update `phase_gates` in `spec-{slug}.md`
+2. Tell the user clearly: "Gate [A/B/C] passed — activate [@next-agent]" OR "Gate [A/B/C] blocked — [reason]. Resolve before continuing."
+
+Never silently assume a gate is passed.

package/template/.aioson/skills/process/aioson-spec-driven/references/artifact-map.md

@@ -0,0 +1,44 @@
+# Artifact Map — AIOSON Spec-Driven
+
+> Source of truth: which artifact lives where, who writes it, who reads it.
+
+## Artifact chain
+
+```
+prd*.md
+  → sheldon-enrichment-{slug}.md   (optional enrichment layer)
+  → requirements-{slug}.md         (entities, rules, ACs — @analyst)
+  → spec-{slug}.md                 (feature memory — @analyst seeds, @dev fills)
+  → architecture.md                (tech decisions — @architect)
+  → design-doc*.md                 (scope-specific decisions — @architect)
+  → implementation-plan-{slug}.md  (execution sequence — @dev)
+  → spec-{slug}.md (updated)       (living state during execution — @dev)
+```
+
+## Artifact ownership
+
+| Artifact | Written by | Enriched by | Read by |
+|----------|-----------|-------------|---------|
+| `prd.md` / `prd-{slug}.md` | @product | @sheldon (via sheldon-enrichment) | all downstream |
+| `sheldon-enrichment-{slug}.md` | @sheldon | @sheldon | @sheldon (re-entry), @analyst |
+| `sheldon-validation.md` | @sheldon | — | all agents before starting MEDIUM |
+| `discovery.md` | @analyst | — | @architect, @dev |
+| `requirements-{slug}.md` | @analyst | — | @architect, @dev, @qa |
+| `spec-{slug}.md` | @analyst (skeleton) | @dev (execution state) | @dev, @deyvin, @qa |
+| `spec.md` | @dev | @dev | @dev, @deyvin |
+| `architecture.md` | @architect | — | @dev, @ux-ui |
+| `design-doc*.md` | @architect | — | @dev, @ux-ui |
+| `implementation-plan-{slug}.md` | @dev | — | @dev, @deyvin |
+
+## Naming conventions
+
+- Project-level artifacts: `prd.md`, `discovery.md`, `spec.md`, `architecture.md`
+- Feature-level artifacts: always use `{slug}` suffix — `prd-{slug}.md`, `requirements-{slug}.md`, `spec-{slug}.md`
+- Enrichment: `sheldon-enrichment.md` (project) or `sheldon-enrichment-{slug}.md` (feature)
+- Plans: `.aioson/plans/{slug}/manifest.md` + `plan-{slug-fase}.md` files
+
+## What NOT to create
+
+- Do not create `.specs/` folders — use the artifact names above
+- Do not rename existing artifacts to match TLC conventions
+- Do not create a new artifact if an existing one covers the same purpose

package/template/.aioson/skills/process/aioson-spec-driven/references/classification-map.md

@@ -0,0 +1,37 @@
+# Classification Map — Phase Depth by Project Size
+
+> Use this when deciding which phases to run and how deep to go.
+
+## Depth table
+
+| Phase | MICRO (0–1) | SMALL (2–3) | MEDIUM (4–6) |
+|-------|-------------|-------------|--------------|
+| Specify (PRD) | 1 conversation, lite template | Full PRD conversation | Full PRD + `## Specify depth` section |
+| Research (@sheldon) | Skip unless links/external sources provided | Recommended — run before @analyst | Required — run Modo C (full validation) |
+| Requirements (@analyst) | Skip — go @product → @dev | Required — `requirements-{slug}.md` | Required — with requirement IDs + ACs |
+| Design (@architect) | Skip unless auth or external integration | Selective — only if new architecture pattern | Required — full `architecture.md` |
+| Plan (implementation-plan) | Optional — suggest only if @dev asks | Recommended | Required — with gate approval + verification criteria |
+| Execute (@dev) | Direct from PRD | From requirements + spec | From approved plan only |
+| State (@dev, @deyvin) | Minimal `spec.md` note | `spec-{slug}.md` with phase_gates | Full spec pack — phase_gates + checkpoints + maintenance notes |
+
+## Scoring (from @analyst)
+
+| Dimension | Score |
+|-----------|-------|
+| User types: 1 | 0 |
+| User types: 2 | 1 |
+| User types: 3+ | 2 |
+| External integrations: 0 | 0 |
+| External integrations: 1–2 | 1 |
+| External integrations: 3+ | 2 |
+| Business rule complexity: none | 0 |
+| Business rule complexity: some | 1 |
+| Business rule complexity: complex | 2 |
+
+**0–1 = MICRO / 2–3 = SMALL / 4–6 = MEDIUM**
+
+## Gate behavior by classification
+
+- **MICRO**: gates are informational, never blocking. @dev may proceed without explicit approval.
+- **SMALL**: Gate A (requirements) is recommended before design. Gate B is optional.
+- **MEDIUM**: Gates A, B, C are required. Do not proceed to next phase without explicit user confirmation.

package/template/.aioson/skills/process/aioson-spec-driven/references/hardening-lane.md

@@ -0,0 +1,49 @@
+# Hardening Lane — From Exploration to Reliable Execution
+
+> Use when input is vague, exploratory, or "vibe-style" and needs to be converted into a spec pack before implementation.
+
+## Two lanes
+
+### Lane 1 — Exploration / Vibe
+- Goal: discover value, direction, and feasibility
+- Tolerates: back-and-forth, open questions, incomplete scope
+- Good for: MVPs, ideas, experiments, early discovery
+- Output: notes, rough PRD, conversation log
+
+### Lane 2 — Spec Hardening
+- Goal: convert exploration into reliable, maintainable execution
+- Requires: requirements, design decisions, checkpoints, and tests
+- Good for: code that will survive, grow, and be maintained
+- Output: spec pack (PRD + requirements + architecture + implementation plan)
+
+**AIOSON's identity is Lane 2.** It does not compete with vibe coding — it is the hardening layer that converts exploration into software that works in production.
+
+## When to harden
+
+Harden before coding when ANY of these are true:
+- The feature involves new entities or database changes
+- The feature integrates with an external service
+- Multiple user types are involved
+- The behavior in error or edge cases matters for production quality
+- Another developer (or AI session) will need to continue this work later
+
+Skip hardening (go direct from PRD to @dev) ONLY when:
+- Classification is confirmed MICRO
+- No new entities, no integrations, pure UI/CRUD
+- The full spec can fit in one session context without losing state
+
+## Signals that input is in vibe mode (not yet hardenable)
+
+- "I want something like X" without defining what X actually does
+- Requirements expressed as UI descriptions ("there should be a button that does Y")
+- No mention of what happens when things go wrong
+- No mention of who can do what (permissions, roles)
+- Scope keeps expanding during the conversation
+
+## What to do when input is in vibe mode
+
+Do not start implementation. Instead:
+1. Acknowledge: "This is still in exploration mode — let's harden it before coding."
+2. Route to @product if no PRD exists yet.
+3. Route to @sheldon if PRD exists but has gaps.
+4. Only proceed to @analyst / @architect / @dev after Gate A is passed.

package/template/.aioson/skills/process/aioson-spec-driven/references/maintenance-and-state.md

@@ -0,0 +1,66 @@
+# Maintenance and State — Writing Useful Checkpoints
+
+> Use when writing or reading `spec*.md`, updating checkpoints, or retaking work after a session break.
+
+## The purpose of spec-{slug}.md
+
+It is not just an implementation log. It is the **living memory** of a feature across all sessions, agents, and tools.
+
+A well-written `spec-{slug}.md` allows:
+- @deyvin to resume from the last checkpoint without re-reading the entire spec pack
+- @qa to know what was decided and what was deferred
+- A future developer (or AI) to understand *why* the code was written the way it was
+
+A poorly written `spec-{slug}.md` forces every new session to rediscover what was already decided.
+
+## What to write in phase_gates
+
+```yaml
+phase_gates:
+  requirements: approved      # requirements are locked — no new scope without PRD change
+  design: approved            # architecture is locked — no structural changes without @architect
+  plan: approved              # execution sequence is locked — @dev follows plan, not instinct
+```
+
+Never mark a gate as `approved` if there are unresolved items in that phase.
+
+## What to write in last_checkpoint
+
+Format: `{phase-name}: {what was completed} — {what is next}`
+
+Examples:
+- `migration: users table created and seeded — next: implement CreateUser action`
+- `auth: login and register complete, password reset pending — next: implement ResetPassword action`
+- `api: GET /products and POST /products done — next: implement PATCH /products/{id}`
+
+This one line is what @deyvin reads first. Make it actionable.
+
+## What to write in pending_review
+
+List items that need human verification before the next phase begins:
+
+```yaml
+pending_review:
+  - "Confirm: should password reset expire after 1h or 24h? (decision was deferred)"
+  - "Review: CreateUser action sends email — confirm SMTP config in staging before testing"
+```
+
+## What to write in Key decisions
+
+Format: `[ISO-date] [decision] — [reason this decision reduces future debug or maintenance cost]`
+
+Bad example:
+- `2026-03-28 Used soft deletes`
+
+Good example:
+- `2026-03-28 Used soft deletes on users table — reason: billing history must remain intact after account deletion; hard delete would orphan invoices`
+
+The reason is what makes the decision useful in 6 months.
+
+## How @deyvin should use this file
+
+1. Read `phase_gates` first — know which phases are locked
+2. Read `last_checkpoint` — start from there, not from the beginning
+3. Read `pending_review` — these may need user input before proceeding
+4. Read `Key decisions` only if the next task involves re-touching those areas
+5. Do NOT re-read the full spec pack unless `last_checkpoint` is null or unclear

package/template/.aioson/skills/process/aioson-spec-driven/references/ui-language.md

@@ -0,0 +1,75 @@
+# UI Language — AIOSON Visual Standards
+
+> Carregue quando um agente precisa apresentar opções, status ou checkpoints ao usuário.
+
+## Status symbols
+✓ completo / aprovado
+✗ falhou / bloqueado
+◆ em progresso
+○ pendente
+⚠ atenção necessária
+⚡ auto-aprovado
+
+## Stage banner
+Usar ao iniciar fase principal:
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+ AIOSON ► @{AGENT} — {FASE}
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+## Checkpoint verify (confirmação visual)
+Usar: após implementação que o usuário precisa ver
+```
+┌─────────────────────────────────────────────┐
+│  ✓ VERIFICAR: {título}                      │
+│  {instrução específica}                      │
+│  Confirmar? [s/n]                           │
+└─────────────────────────────────────────────┘
+```
+
+## Checkpoint decision (AskUserQuestion — radio)
+Usar: quando há bifurcação com outcomes diferentes
+→ AskUserQuestion com multiSelect: false, 2-4 opções
+
+```
+┌─────────────────────────────────────────────┐
+│  ◆ DECISÃO NECESSÁRIA                      │
+│                                             │
+│  {contexto da decisão}                      │
+│                                             │
+│  1. {opção A} — {consequências}            │
+│  2. {opção B} — {consequências}            │
+│                                             │
+│  Escolha [1/2]:                            │
+└─────────────────────────────────────────────┘
+```
+
+## Checkpoint action (passo manual)
+Usar: apenas para passos que o agente literalmente não pode executar
+```
+┌─────────────────────────────────────────────┐
+│  ⚠ AÇÃO MANUAL NECESSÁRIA                  │
+│                                             │
+│  {instrução específica}                      │
+│  {onde executar}                             │
+│                                             │
+│  Avise quando estiver pronto.              │
+└─────────────────────────────────────────────┘
+```
+
+## Checkpoint multi-select (AskUserQuestion — checkbox)
+Usar: seleção múltipla (skills, requirements, itens de sprint)
+→ AskUserQuestion com multiSelect: true
+
+## Progress bar
+Usar para fases longas com steps definidos:
+```
+Progresso: ████████░░ 80% (4/5 steps)
+```
+
+## Regras
+- Header máximo 12 caracteres
+- Máximo 4 opções em radio; máximo 8 em checkbox
+- Incluir opção "Nenhuma/Pular" em checkbox quando pertinente
+- Não usar checkbox para decisões que mudam arquitetura (use radio)

package/template/.aioson/skills/process/design-hybrid-forge/SKILL.md

@@ -0,0 +1,144 @@
+---
+name: design-hybrid-forge
+description: Process skill that creates project-local hybrid design skills by fusing exactly two primary AIOSON design skills, with optional limited modifiers. When activated, guides you through pair selection, identity synthesis, crossover spec, skill generation, preview creation, metadata, and optional promotion.
+activation: |
+  You are now running the design-hybrid-forge process. Begin by asking the user for the names of the two primary AIOSON design skills they want to combine, then ask whether they want optional modifiers. Use up to two modifiers by default, or up to three only when the active variation preset or the user explicitly enables advanced mode. Follow the phases described in this skill.
+---
+
+# Skill: design-hybrid-forge
+
+> Process skill. Creates new hybrid design skills by fusing DNA from two existing AIOSON design skills.
+> Load this file first. Then load only the `references/` file you need for your current phase.
+
+## What this skill produces
+
+A complete, production-quality hybrid design skill package for the current project:
+
+```
+.aioson/installed-skills/{hybrid-name}/
+  SKILL.md
+  .skill-meta.json
+  references/
+    art-direction.md
+    design-tokens.md
+    components.md
+    patterns.md
+    dashboards.md
+    websites.md
+    motion.md
+  previews/
+    {hybrid-name}.html
+    {hybrid-name}-website.html
+```
+
+If tool-native skill folders exist, the finished package may also be mirrored to:
+
+```
+.claude/skills/{hybrid-name}/
+.cursor/skills/{hybrid-name}/
+.windsurf/skills/{hybrid-name}/
+```
+
+## When to load
+
+Load this skill when:
+- You want to create a new hybrid design skill from two base skills
+- You are planning this week's hybrid (pair selection phase)
+- You are executing the crossover (generation phase)
+- You need to validate a hybrid before shipping
+- You want an anti-sameness variation overlay for a more extravagant, classic, animated, or CSS-advanced result
+
+Do NOT load this skill to apply a design skill to a project. Use the target hybrid's own SKILL.md for that.
+
+## Output modes
+
+### 1. Project-local installed skill (default)
+
+Use this mode in normal AIOSON projects.
+
+- Writes the new hybrid to `.aioson/installed-skills/{hybrid-name}/`
+- Keeps the skill versioned with the project
+- Generates local previews inside the skill folder
+- Records author / generator metadata in `.skill-meta.json`
+- Does not touch AIOSON core galleries or first-party skill folders
+
+### 2. Core promotion (optional)
+
+Use this mode only when the user explicitly wants to propose the hybrid back to AIOSON core or marketplace curation.
+
+- Starts from an already-generated project-local skill
+- Prepares promotion artifacts for `.aioson/skills/design/{hybrid-name}/`
+- Updates gallery / registry files only in the core repo
+- Must stay a separate step from project-local generation
+
+## Process overview
+
+| Phase | What happens | Produces |
+|---|---|---|
+| **1. Pair Selection** | Choose 2 primary skills with creative tension | Chosen pair + rationale |
+| **2. Identity Synthesis** | Name, 3 pillars, accent fusion, substrate | Hybrid identity doc (in conversation) |
+| **3. Crossover Spec** | Define DNA from A, DNA from B, optional modifiers, new elements | Crossover map (in conversation) |
+| **4. Skill Generation** | Write SKILL.md + 7 reference files + metadata | Skill package |
+| **5. Preview Generation** | Write dashboard HTML + landing HTML inside the skill package | 2 `.html` files |
+| **6. Distribution** | Register in `AGENTS.md` and mirror to tool-native skill folders if present | Tool-ready copies |
+| **7. Optional Promotion** | Prepare for core/gallery/marketplace only if requested | Promotion bundle |
+
+Each phase must complete before the next begins. Do not skip phase 2 and 3 — they are what makes the hybrid coherent rather than a random blend.
+
+## Input contract
+
+```
+primary_a: {skill-name}            # e.g. "cognitive-core-ui"
+primary_b: {skill-name}            # e.g. "glassmorphism-ui"
+modifiers: {optional 0..2}         # e.g. ["bold-editorial-ui"]
+variation_overlay: {optional}      # selected via conversation or `aioson design-hybrid:options`
+modifier_policy: {optional}        # "up_to_2_modifiers" by default, "up_to_3_modifiers" in advanced mode
+name_suggestion: {optional}        # e.g. "aurora-command-ui" or leave blank
+target_domain: {optional}          # e.g. "SOC platform" — narrows expression modes
+author_name: {optional}            # e.g. "Jaime" or "ACME Design Team"
+generator_model: {optional}        # fill if the runtime/tool exposes it
+```
+
+## Output contract
+
+The hybrid must satisfy ALL of the following:
+- 8 files (SKILL.md + 7 references) with full content — no placeholders
+- 1 metadata file: `.skill-meta.json`
+- 2 HTML previews: dashboard (operational) + landing page (marketing)
+- A name that is original and not a concatenation of the parent names
+- A new accent that is NOT identical to either parent's accent
+- A substrate rule that is clearly stated and non-negotiable
+- At minimum 5 expression modes in art-direction.md
+- At minimum 20 components in components.md
+- Exactly 2 primary parents
+- At most 2 optional modifiers with limited scope by default
+- Up to 3 modifiers only when advanced mode is explicitly enabled
+- A single coherent visual system that can be selected as one `design_skill`
+- Metadata that records authorship and generator/model details when available
+- When a variation overlay exists, the generated skill and previews must visibly express it
+- When a temporary variation preset exists, it must be archived or removed from active context after successful generation
+
+## References available
+
+| File | Load when |
+|---|---|
+| `references/pair-compatibility.md` | Choosing which two skills to combine this week |
+| `references/crossover-protocol.md` | Running phases 2 and 3 (identity + crossover spec) |
+| `references/variation-library.md` | Choosing a variation overlay or anti-sameness directions |
+| `references/output-contract.md` | Running phases 4 and 5 (file generation) |
+| `references/naming-registry.md` | Naming the hybrid and checking for conflicts |
+| `references/quality-gates.md` | Validating the hybrid before shipping (distribution / promotion gates) |
+
+## Non-negotiable rules
+
+1. Exactly 2 primary parents are required. Never generate a hybrid with 3 or 4 co-equal parents.
+2. Optional modifiers are capped at 2 by default. A 3rd modifier is allowed only in advanced mode and still cannot own substrate or structure.
+3. The hybrid must have its own identity — not "A with B colors" but a third thing.
+4. The crossover spec must be explicit: what comes from each primary parent, what modifiers influence, and what is new.
+5. The accent must be a genuine fusion — not parent A's accent, not parent B's. A new value or gradient pair.
+6. The substrate rule is always the first decision. One primary parent wins the background model.
+7. The hybrid's SKILL.md must explicitly name its parents in a `## Hybrid DNA` section.
+8. Never combine two primary skills from the same family (e.g. cognitive-core + premium-command = too similar).
+9. Every hybrid ships with both previews and a `.skill-meta.json`. No preview = not done.
+10. Project-local generation goes to `.aioson/installed-skills/` by default. Promotion to core is a separate, explicit step.
+11. `design-hybrid:options` creates a temporary preset in `.aioson/context/design-variation-preset.md`; after successful generation, archive or remove the active preset and preserve the history snapshot.