sinapse-ai 1.21.0 → 1.23.0

package/.claude/rules/mandatory-delegation.md

@@ -2,6 +2,9 @@
 
 > **Constitution Article VIII — NON-NEGOTIABLE**
 > Applies to Imperator (sinapse-orqx) and ALL orchestrator agents (*-orqx).
+> This is the always-on CORE (the law). The full delegation matrices (framework
+> agents + squad orchestrators), own-domain table, and handoff detail live in
+> `mandatory-delegation-reference.md` and load when you work on agent/squad files.
 
 ## Rule
 
@@ -12,109 +15,42 @@ Orchestrators NEVER execute domain work directly. They ALWAYS:
 3. **Delegate** — Route to the appropriate specialist agent
 4. **Coordinate** — Track progress and handle handoffs between agents
 
-This is AUTOMATIC and INVIOLABLE. The user never needs to ask for delegation — it happens on every single request.
+This is AUTOMATIC and INVIOLABLE — the user never needs to ask for delegation.
 
 ## Even When Explicitly Asked
 
-If the user says ANY of these:
-- "voce faz"
-- "faz voce mesmo"
-- "nao delega, faz direto"
-- "I want YOU to write the code"
-- "just do it yourself"
-- "implementa isso ai"
-
-The orchestrator MUST still delegate. The correct response pattern is:
+If the user says "voce faz", "faz voce mesmo", "nao delega", "I want YOU to write
+the code", "just do it yourself", "implementa isso ai" — the orchestrator MUST
+still delegate:
 
 > "Absorvi o briefing. Delegando para @{specialist-agent} que e o especialista nesse dominio."
 
-**NEVER** execute the work directly. **ALWAYS** delegate to the specialist, no matter what the user says.
-
-## Delegation Matrix
-
-### Framework Agents (Development Workflow)
-
-| Request Type | Delegate To |
-|-------------|-------------|
-| Code implementation | @developer (Pixel) |
-| Story creation | @sprint-lead (Sync) |
-| Story validation | @product-lead (Axis) |
-| Architecture decisions | @architect (Stratum) |
-| Quality/testing | @quality-gate (Litmus) |
-| Database work | @data-engineer (Tensor) |
-| UX/UI design | @ux-design-expert (Mosaic) |
-| Git push/PR/release | @devops (Pipeline) |
-| Epic orchestration | @project-lead (Beacon) |
-| Research/analysis | @analyst (Scope) |
-
-### Squad Orchestrators (Domain Expertise)
-
-| Request Domain | Delegate To |
-|---------------|-------------|
-| Branding, identidade visual | @brand-orqx (Meridian) |
-| Vendas, CRM, pipeline | @commercial-orqx (Pipeline) |
-| Conteudo, editorial | @content-orqx |
-| Copywriting, persuasao | @copy-orqx (Quill) |
-| Animacoes web, motion | @animations-orqx (Kinetic) |
-| UX/UI, design system | @design-orqx (Nexus) |
-| Financeiro, pricing | @finance-orqx (Ledger) |
-| Growth, SEO, analytics | @growth-orqx (Catalyst) |
-| Midia paga, ads | @paidmedia-orqx (Apex) |
-| Produto, roadmap | @product-orqx (Vector) |
-| Pesquisa, inteligencia | @research-orqx (Prism) |
-| Claude Code mastery | @swarm-orqx (Relay) |
-| Conselho estrategico | @council-orqx (Zenith) |
-| Storytelling, pitch | @storytelling-orqx (Arc) |
-| Cybersecurity | @cyber-orqx (Fortress) |
-| Clonagem cognitiva | @cloning-orqx (Helix) |
-| Cursos, workshops | @courses-orqx (Syllabus) |
-
-## What Orchestrators CAN Do (their actual domain)
-
-Orchestrators have their OWN domain of expertise:
-
-| Orchestrator | Own Domain (can execute directly) |
-|-------------|----------------------------------|
-| Imperator (sinapse-orqx) | Routing, diagnostico, plano de orquestracao, coordenacao cross-squad, framework governance |
-| Squad *-orqx | Routing intra-squad, coordenacao de agentes do squad, handoff management |
-
-Everything OUTSIDE their orchestration domain MUST be delegated.
-
-## Anti-Patterns (FORBIDDEN)
-
-- Orchestrator writing application code
-- Orchestrator making architectural decisions without @architect
-- Orchestrator creating stories without @sprint-lead
-- Orchestrator running quality checks without @quality-gate
-- Orchestrator doing database work without @data-engineer
-- Orchestrator doing ANY specialist work outside of orchestration
-- Saying "vou fazer isso eu mesmo" instead of delegating
-- Absorbing a request and executing it instead of routing
-
-## Universal Auto-Routing (users should NEVER call agents manually)
+**NEVER** execute the work directly. **ALWAYS** delegate to the specialist.
 
-Users are NOT AI experts. The system MUST understand natural language and route automatically.
+## Universal Auto-Routing
 
-**On EVERY user message (not just orchestrator):**
-1. Detect the domain of the request
-2. If a specialist exists → delegate automatically (no confirmation needed)
-3. Brief acknowledgment: "Delegando para @specialist..."
-4. Return the result to the user
+Users are NOT AI experts. On EVERY user message: detect the domain → if a
+specialist exists, delegate automatically (no confirmation) → brief
+acknowledgment → return the result. Cross-agent handoffs (push → @devops,
+tests → @quality-gate, schema → @data-engineer, story → @sprint-lead,
+architecture → @architect) are automatic — never ask the user.
 
-**Auto-detect project state on first interaction:**
-- Check for `.sinapse-ai/` → SINAPSE-managed (continue SDC)
-- Check for `package.json` or `.git` → Brownfield (run quick tech scan first)
-- Empty directory → Greenfield (ask project type, scaffold)
+## Enforcement
 
-**Cross-agent handoff (automatic, never ask user):**
-- Agent needs git push → auto-delegate to @devops
-- Agent needs tests → auto-delegate to @quality-gate
-- Agent needs schema → auto-delegate to @data-engineer
-- Agent needs story → auto-create via fast-track or @sprint-lead
-- Agent needs architecture decision → auto-delegate to @architect
+Any orchestrator response containing direct domain work (code, schema, copy, etc.)
+without having first delegated is a **constitutional violation** — correct it
+immediately. Asking the user to manually invoke an agent (`@agent-name`,
+`/SINAPSE:agents:...`) instead of auto-routing is a **UX violation**.
 
-## Enforcement
+## Anti-Patterns (FORBIDDEN)
 
-Any response from an orchestrator that contains direct domain work (code, schema, copy, etc.) without having first delegated to the appropriate specialist is a **constitutional violation** and must be corrected immediately.
+- Orchestrator writing application code, making architecture decisions without
+  @architect, creating stories without @sprint-lead, running quality gates
+  without @quality-gate, or doing ANY specialist work outside orchestration
+- Saying "vou fazer isso eu mesmo" instead of delegating
+- Absorbing a request and executing it instead of routing
 
-Any response that asks the user to manually invoke an agent (showing `@agent-name` or `/SINAPSE:agents:...` commands) instead of auto-routing is a **UX violation** — the system should just do it.
+> **Detail (loads on agent/squad work):** full delegation matrices (framework
+> agents + 17 squad orchestrators), what orchestrators CAN do (own domain),
+> auto-detect of project state, cross-agent handoff list — see
+> `mandatory-delegation-reference.md`.

package/.claude/rules/project-intelligence-reference.md

@@ -0,0 +1,159 @@
+---
+paths:
+  - "package.json"
+  - "core-config.yaml"
+  - "docs/prd.md"
+  - "docs/project-brief.md"
+  - "docs/epics/**"
+  - "docs/stories/**"
+  - ".sinapse-ai/**"
+---
+
+# Project Intelligence — Operational Reference
+
+> Companion to `project-intelligence.md` (the always-on core law). This file carries
+> the per-dimension signals, behaviors and examples and loads when you work on
+> project-setup files.
+
+## Initial State Audit — signals per dimension
+
+The audit collects existence + summary for each dimension. Each is a YES/NO/PARTIAL signal:
+
+| # | Dimension | Signals checked |
+|---|---|---|
+| 1 | **Docs** | `docs/project-brief.md`, `docs/prd.md`, `docs/architecture*.md`, `docs/front-end-spec.md`, `docs/epics/`, `docs/stories/` |
+| 2 | **Brand** | `brand/`, `brandbook*`, `assets/brand/`, `public/brand/`, `*logo*`, `BRAND.md`, `BRANDBOOK.md` |
+| 3 | **Design system** | `tokens.json`, `design-tokens.json`, `tailwind.config.*` with custom theme, `components/ui/`, `DESIGN.md`, `DS.md` |
+| 4 | **Components** | `components/`, `src/components/`, `app/`, `pages/` with `.tsx` / `.jsx` / `.vue` files |
+| 5 | **Code** | `package.json`, `tsconfig.json`, `src/`, language-specific markers (`go.mod`, `pyproject.toml`, `Cargo.toml`) |
+| 6 | **Tests** | `jest.config.*`, `vitest.config.*`, `__tests__/`, `tests/`, `*.test.*`, `*.spec.*` |
+| 7 | **Infra** | `.github/workflows/`, `Dockerfile`, `docker-compose.*`, `vercel.json`, `.env.example`, CI configs |
+| 8 | **Git history** | `.git/` exists, `git log` has commits, recent activity (last 30 days), branch count |
+
+### Maturity classification — criteria
+
+| Level | Criteria | Recommended workflow |
+|---|---|---|
+| `EMPTY` | 0/8 signals; directory has only `.git/` or nothing | Full greenfield workflow (greenfield-handler.js) |
+| `BOOTSTRAPPED` | Only Infra (7) present (CI, Dockerfile, .env.example) — no code yet | Skip Phase 0 Bootstrap, jump to Phase 1 Discovery |
+| `PARTIAL` | Some Docs/Brand/DS but no Code, OR Code without Docs | **Continue from where it stopped** — never overwrite, merge with existing |
+| `MATURE` | Code + Tests + (Docs OR Infra) — real working project | Brownfield Discovery (10-phase technical debt) before any change |
+| `SINAPSE_MANAGED` | `.sinapse-ai/` exists with `core-config.yaml` | Resume SDC: read `docs/stories/`, find active story, continue |
+
+### Audit output (always presented to user before proceeding)
+
+```
+Estado detectado: {maturity_level}
+Já existe: {list of YES dimensions, e.g., "Brand (logo + brandbook), 1 PRD parcial em docs/, 5 componentes UI"}
+Faltando: {list of NO dimensions critical to the user's request}
+Recomendação: {workflow + concrete first step}
+```
+
+### Anti-shortcuts (FORBIDDEN)
+
+- Skipping the audit because "it looks empty" — always run, always check all 8 dimensions
+- Calling a directory "greenfield" because `package.json` is missing (could have brand assets, half-written PRD, design tokens — all without `package.json`)
+- Calling a directory "brownfield" only because `package.json` exists (could be just bootstrapped infra with zero feature work — different workflow)
+- Overwriting existing partial work without listing it to the user first
+- Ignoring `docs/epics/` and `docs/stories/` from a previous session
+
+## Quick Tech Scan (BROWNFIELD, < 5 seconds)
+
+When brownfield detected, silently check:
+
+| Check | How | Sets Context |
+|-------|-----|-------------|
+| Framework | package.json dependencies | next/react/vue/angular/express |
+| Language | tsconfig.json exists? | typescript/javascript |
+| Database | supabase/, prisma/, .env | supabase/prisma/drizzle/none |
+| Tests | jest.config, vitest.config | jest/vitest/none |
+| CI | .github/workflows/ | github-actions/none |
+
+Report to user in ONE line: "Projeto Next.js + TypeScript + Supabase detectado."
+
+## Behavior Adaptation by State
+
+### Greenfield Behavior
+
+A bare `setup → story → implement` loop is **not enough** for greenfield. Large projects need upstream artifacts (project-brief, PRD, architecture, design spec) BEFORE stories. The greenfield branch sub-classifies the request and invokes the right workflow.
+
+#### Step 1 — Sub-classify project_type
+
+Detect intent and target from the user's first message (PT-BR or EN keywords):
+
+| project_type | Triggers |
+|---|---|
+| `site` | site, website, institucional, página, web page |
+| `lp` | landing page, LP, captura, sales page, squeeze page |
+| `app` | app mobile, ios, android, react native, flutter |
+| `platform` | plataforma, dashboard, admin panel, portal interno |
+| `saas` | SaaS, software as a service, app web com login, multi-tenant |
+| `api` | API, backend, REST, GraphQL, microservice |
+| `service` | worker, cron job, ETL, integration, automation |
+
+If detection is ambiguous, ask ONE clarifying question with these options as choices.
+
+#### Step 2 — Map to required workflow
+
+| project_type | Workflow file | Phase 1 agents |
+|---|---|---|
+| `site` / `lp` / `app` | `.sinapse-ai/development/workflows/greenfield-ui.yaml` | analyst → project-lead → ux-design-expert → architect → product-lead |
+| `platform` / `saas` | `.sinapse-ai/development/workflows/greenfield-fullstack.yaml` | analyst → project-lead → ux-design-expert → architect → product-lead |
+| `api` / `service` | `.sinapse-ai/development/workflows/greenfield-service.yaml` | analyst → project-lead → architect → product-lead |
+
+Execution mechanism: `.sinapse-ai/core/orchestration/greenfield-handler.js` orchestrates Phase 0 (Bootstrap) → Phase 1 (Discovery 5-agent) → Phase 2 (Sharding) → Phase 3 (Dev Cycle).
+
+#### Step 3 — Apply DS grounding (UI projects)
+
+For `site` / `lp` / `app` / `platform` / `saas`, the DS Resolver runs before any visual output (see `~/.claude/rules/design-system-grounding.md`). Internal projects use the SINAPSE Brandbook; external clients use the client's brand or the high-quality fallback.
+
+#### Step 4 — Forbidden shortcut
+
+The greenfield branch NEVER skips to "implement" without:
+- `docs/project-brief.md` validated
+- `docs/prd.md` validated
+- `docs/{front-end-spec | service-architecture}.md` validated
+- `docs/architecture.md` (or `fullstack-architecture.md`) validated
+- Stories in `docs/stories/` with status ≥ Ready
+
+#### Auto-apply infra templates
+
+Independent of project_type: PR template, CI, `.env.example`, CODEOWNERS, gitignore. These run during Phase 0 (Bootstrap) of the greenfield workflow.
+
+### Continuation Behavior (PARTIAL maturity)
+
+When the audit detects partial work — e.g., a brandbook without a site, a PRD without code, components without architecture, an abandoned epic — the framework MUST treat it as a continuation, not a bootstrap.
+
+- **Inventory first:** list every existing artifact and tell the user what's there
+- **Identify gaps:** what's missing to ship the user's stated goal?
+- **Propose continuation plan:** which greenfield phase resumes from here? which brownfield steps apply?
+- **Merge, never replace:** existing brand/DS/components are inputs to the workflow, not throwaway scaffolding
+- **Preserve epic + story state:** if `docs/epics/` or `docs/stories/` exist, resume their lifecycle (Draft → Ready → InProgress → Done)
+
+Example: user says "criar um site" but the audit finds a `brand/` folder with logo + brandbook. The framework reports:
+> Estado: `PARTIAL`. Já existe: brand assets (logo + brandbook). Faltando: PRD, design spec, código. Recomendação: greenfield-ui.yaml começando da Phase 1, usando seu brandbook como input.
+
+### Brownfield Behavior (MATURE maturity)
+- Prioritize: understanding existing code before changing anything
+- First action: read README, package.json, folder structure
+- Workflow: quick scan → understand → then proceed with user request
+- NEVER rewrite or refactor without understanding existing patterns
+- Respect existing conventions (naming, folder structure, testing framework)
+- For non-trivial changes: invoke Brownfield Discovery (10-phase technical debt assessment)
+
+### SINAPSE-Managed Behavior
+- Check for active story in docs/stories/
+- Resume where last session left off
+- Follow SDC workflow (story → implement → QA → push)
+
+## Anti-Patterns (FORBIDDEN) — full list
+
+- Asking user "is this a new or existing project?"
+- Asking user to set `projectType` in config
+- Starting implementation in brownfield without reading existing code first
+- Applying greenfield templates to a brownfield project (overwriting existing CI/configs)
+- Ignoring existing patterns and imposing SINAPSE conventions forcefully
+- Treating greenfield as "setup → story → implement" without sub-classifying project_type
+- Skipping `greenfield-handler.js` (or its workflow file) on a `site` / `lp` / `platform` / `saas` / `api` request
+- Letting a domain orchestrator (design, brand) generate visual output before greenfield Phase 1 produces project-brief.md + prd.md + design spec
+- Generating UI without DS grounding (see `~/.claude/rules/design-system-grounding.md`)

package/.claude/rules/project-intelligence.md

@@ -1,168 +1,50 @@
 # Project Intelligence — Auto-Detection (NON-NEGOTIABLE)
 
 > Applies to ALL agents, ALL sessions. Users NEVER configure project type manually.
+> This is the always-on CORE (the law). The per-dimension signals, per-state
+> behaviors (greenfield / continuation / brownfield / SINAPSE-managed) and examples
+> live in `project-intelligence-reference.md` and load when you work on
+> project-setup files.
 
-## Initial State Audit (ALWAYS FIRST — runs before classification)
+## Initial State Audit (ALWAYS FIRST — NON-NEGOTIABLE preflight)
 
-> **This is a NON-NEGOTIABLE preflight step.** Without it, the framework treats every fresh-looking directory as "greenfield" and ignores partial work that's already there (existing brand, components, half-written PRD, abandoned epics, an in-progress design system, brownfield code with no `package.json`, etc.). The audit costs ~2 seconds and prevents the framework from overwriting or duplicating work.
+Before classifying anything, silently audit **8 dimensions** (existence + summary):
+**Docs · Brand · Design system · Components · Code · Tests · Infra · Git history.**
+Never skip it "because it looks empty" — partial work (brand without code, a
+half-written PRD, abandoned epics) is exactly what the audit protects.
 
-### Eight dimensions to check (silent, parallel)
+## Maturity Classification (from the 8 signals)
 
-The audit collects existence + summary for each dimension. Each is a YES/NO/PARTIAL signal:
-
-| # | Dimension | Signals checked |
-|---|---|---|
-| 1 | **Docs** | `docs/project-brief.md`, `docs/prd.md`, `docs/architecture*.md`, `docs/front-end-spec.md`, `docs/epics/`, `docs/stories/` |
-| 2 | **Brand** | `brand/`, `brandbook*`, `assets/brand/`, `public/brand/`, `*logo*`, `BRAND.md`, `BRANDBOOK.md` |
-| 3 | **Design system** | `tokens.json`, `design-tokens.json`, `tailwind.config.*` with custom theme, `components/ui/`, `DESIGN.md`, `DS.md` |
-| 4 | **Components** | `components/`, `src/components/`, `app/`, `pages/` with `.tsx` / `.jsx` / `.vue` files |
-| 5 | **Code** | `package.json`, `tsconfig.json`, `src/`, language-specific markers (`go.mod`, `pyproject.toml`, `Cargo.toml`) |
-| 6 | **Tests** | `jest.config.*`, `vitest.config.*`, `__tests__/`, `tests/`, `*.test.*`, `*.spec.*` |
-| 7 | **Infra** | `.github/workflows/`, `Dockerfile`, `docker-compose.*`, `vercel.json`, `.env.example`, CI configs |
-| 8 | **Git history** | `.git/` exists, `git log` has commits, recent activity (last 30 days), branch count |
-
-### Maturity classification
-
-Combining the 8 signals produces 1 of 5 maturity levels:
-
-| Level | Criteria | Recommended workflow |
+| Level | Meaning | Path |
 |---|---|---|
-| `EMPTY` | 0/8 signals; directory has only `.git/` or nothing | Full greenfield workflow (greenfield-handler.js) |
-| `BOOTSTRAPPED` | Only Infra (7) present (CI, Dockerfile, .env.example) — no code yet | Skip Phase 0 Bootstrap, jump to Phase 1 Discovery |
-| `PARTIAL` | Some Docs/Brand/DS but no Code, OR Code without Docs | **Continue from where it stopped** — never overwrite, merge with existing |
-| `MATURE` | Code + Tests + (Docs OR Infra) — real working project | Brownfield Discovery (10-phase technical debt) before any change |
-| `SINAPSE_MANAGED` | `.sinapse-ai/` exists with `core-config.yaml` | Resume SDC: read `docs/stories/`, find active story, continue |
-
-### Audit output (always presented to user before proceeding)
+| `EMPTY` | 0/8 signals | Full greenfield workflow |
+| `BOOTSTRAPPED` | only Infra present | Greenfield from Phase 1 (skip Bootstrap) |
+| `PARTIAL` | some Docs/Brand/DS without Code, or Code without Docs | **Continue** — never overwrite, merge with existing |
+| `MATURE` | Code + Tests + (Docs OR Infra) | Brownfield Discovery before any change |
+| `SINAPSE_MANAGED` | `.sinapse-ai/` + `core-config.yaml` | Resume SDC from active story |
+
+**Audit output is always presented to the user before proceeding** (one structured
+PT-BR paragraph: estado detectado · já existe · faltando · recomendação). Only
+after this report does the framework classify + invoke workflows.
+
+## The Law
+
+- **Auto-detect, never ask** "is this a new or existing project?" or make the user
+  set `projectType`.
+- **Brownfield:** understand existing code BEFORE changing anything; respect
+  existing conventions; never impose SINAPSE conventions forcefully.
+- **Partial work is sacred:** inventory first, merge — never replace; preserve
+  epic/story state from previous sessions.
+- **Greenfield is NOT "setup → story → implement":** sub-classify the project type
+  and run the required greenfield workflow with its upstream artifacts.
 
-After running the audit, the framework reports in ONE structured paragraph (PT-BR):
-
-```
-Estado detectado: {maturity_level}
-Já existe: {list of YES dimensions, e.g., "Brand (logo + brandbook), 1 PRD parcial em docs/, 5 componentes UI"}
-Faltando: {list of NO dimensions critical to the user's request}
-Recomendação: {workflow + concrete first step}
-```
-
-Only AFTER this report (and any user adjustment) does the framework proceed to classification + workflow invocation.
-
-### Anti-shortcuts (FORBIDDEN)
+## Anti-Patterns (FORBIDDEN)
 
-- Skipping the audit because "it looks empty" — always run, always check all 8 dimensions
-- Calling a directory "greenfield" because `package.json` is missing (could have brand assets, half-written PRD, design tokens — all without `package.json`)
-- Calling a directory "brownfield" only because `package.json` exists (could be just bootstrapped infra with zero feature work — different workflow)
+- Skipping the audit; calling a directory greenfield/brownfield from one signal
 - Overwriting existing partial work without listing it to the user first
 - Ignoring `docs/epics/` and `docs/stories/` from a previous session
+- Applying greenfield templates over an existing project's CI/configs
 
-## Classification (after audit)
-
-Use the maturity level from the audit to pick the path:
-
-```
-maturity == EMPTY              → Full greenfield (see Greenfield Behavior below)
-maturity == BOOTSTRAPPED       → Greenfield Phase 1 onward (skip Bootstrap)
-maturity == PARTIAL            → Continuation Behavior (below)
-maturity == MATURE             → Brownfield Behavior (below)
-maturity == SINAPSE_MANAGED    → SINAPSE-Managed Behavior (below)
-```
-
-## Quick Tech Scan (BROWNFIELD, < 5 seconds)
-
-When brownfield detected, silently check:
-
-| Check | How | Sets Context |
-|-------|-----|-------------|
-| Framework | package.json dependencies | next/react/vue/angular/express |
-| Language | tsconfig.json exists? | typescript/javascript |
-| Database | supabase/, prisma/, .env | supabase/prisma/drizzle/none |
-| Tests | jest.config, vitest.config | jest/vitest/none |
-| CI | .github/workflows/ | github-actions/none |
-
-Report to user in ONE line: "Projeto Next.js + TypeScript + Supabase detectado."
-
-## Behavior Adaptation by State
-
-### Greenfield Behavior
-
-A bare `setup → story → implement` loop is **not enough** for greenfield. Large projects need upstream artifacts (project-brief, PRD, architecture, design spec) BEFORE stories. The greenfield branch sub-classifies the request and invokes the right workflow.
-
-#### Step 1 — Sub-classify project_type
-
-Detect intent and target from the user's first message (PT-BR or EN keywords):
-
-| project_type | Triggers |
-|---|---|
-| `site` | site, website, institucional, página, web page |
-| `lp` | landing page, LP, captura, sales page, squeeze page |
-| `app` | app mobile, ios, android, react native, flutter |
-| `platform` | plataforma, dashboard, admin panel, portal interno |
-| `saas` | SaaS, software as a service, app web com login, multi-tenant |
-| `api` | API, backend, REST, GraphQL, microservice |
-| `service` | worker, cron job, ETL, integration, automation |
-
-If detection is ambiguous, ask ONE clarifying question with these options as choices.
-
-#### Step 2 — Map to required workflow
-
-| project_type | Workflow file | Phase 1 agents |
-|---|---|---|
-| `site` / `lp` / `app` | `.sinapse-ai/development/workflows/greenfield-ui.yaml` | analyst → project-lead → ux-design-expert → architect → product-lead |
-| `platform` / `saas` | `.sinapse-ai/development/workflows/greenfield-fullstack.yaml` | analyst → project-lead → ux-design-expert → architect → product-lead |
-| `api` / `service` | `.sinapse-ai/development/workflows/greenfield-service.yaml` | analyst → project-lead → architect → product-lead |
-
-Execution mechanism: `.sinapse-ai/core/orchestration/greenfield-handler.js` orchestrates Phase 0 (Bootstrap) → Phase 1 (Discovery 5-agent) → Phase 2 (Sharding) → Phase 3 (Dev Cycle).
-
-#### Step 3 — Apply DS grounding (UI projects)
-
-For `site` / `lp` / `app` / `platform` / `saas`, the DS Resolver runs before any visual output (see `~/.claude/rules/design-system-grounding.md`). Internal projects use the SINAPSE Brandbook; external clients use the client's brand or the high-quality fallback.
-
-#### Step 4 — Forbidden shortcut
-
-The greenfield branch NEVER skips to "implement" without:
-- `docs/project-brief.md` validated
-- `docs/prd.md` validated
-- `docs/{front-end-spec | service-architecture}.md` validated
-- `docs/architecture.md` (or `fullstack-architecture.md`) validated
-- Stories in `docs/stories/` with status ≥ Ready
-
-#### Auto-apply infra templates
-
-Independent of project_type: PR template, CI, `.env.example`, CODEOWNERS, gitignore. These run during Phase 0 (Bootstrap) of the greenfield workflow.
-
-### Continuation Behavior (PARTIAL maturity)
-
-When the audit detects partial work — e.g., a brandbook without a site, a PRD without code, components without architecture, an abandoned epic — the framework MUST treat it as a continuation, not a bootstrap.
-
-- **Inventory first:** list every existing artifact and tell the user what's there
-- **Identify gaps:** what's missing to ship the user's stated goal?
-- **Propose continuation plan:** which greenfield phase resumes from here? which brownfield steps apply?
-- **Merge, never replace:** existing brand/DS/components are inputs to the workflow, not throwaway scaffolding
-- **Preserve epic + story state:** if `docs/epics/` or `docs/stories/` exist, resume their lifecycle (Draft → Ready → InProgress → Done)
-
-Example: user says "criar um site" but the audit finds a `brand/` folder with logo + brandbook. The framework reports:
-> Estado: `PARTIAL`. Já existe: brand assets (logo + brandbook). Faltando: PRD, design spec, código. Recomendação: greenfield-ui.yaml começando da Phase 1, usando seu brandbook como input.
-
-### Brownfield Behavior (MATURE maturity)
-- Prioritize: understanding existing code before changing anything
-- First action: read README, package.json, folder structure
-- Workflow: quick scan → understand → then proceed with user request
-- NEVER rewrite or refactor without understanding existing patterns
-- Respect existing conventions (naming, folder structure, testing framework)
-- For non-trivial changes: invoke Brownfield Discovery (10-phase technical debt assessment)
-
-### SINAPSE-Managed Behavior
-- Check for active story in docs/stories/
-- Resume where last session left off
-- Follow SDC workflow (story → implement → QA → push)
-
-## Anti-Patterns (FORBIDDEN)
-
-- Asking user "is this a new or existing project?"
-- Asking user to set `projectType` in config
-- Starting implementation in brownfield without reading existing code first
-- Applying greenfield templates to a brownfield project (overwriting existing CI/configs)
-- Ignoring existing patterns and imposing SINAPSE conventions forcefully
-- Treating greenfield as "setup → story → implement" without sub-classifying project_type
-- Skipping `greenfield-handler.js` (or its workflow file) on a `site` / `lp` / `platform` / `saas` / `api` request
-- Letting a domain orchestrator (design, brand) generate visual output before greenfield Phase 1 produces project-brief.md + prd.md + design spec
-- Generating UI without DS grounding (see `~/.claude/rules/design-system-grounding.md`)
+> **Detail (loads on setup work):** signals checked per dimension, quick tech scan
+> table, per-state behaviors (greenfield steps 1-4, continuation, brownfield,
+> SINAPSE-managed), examples — see `project-intelligence-reference.md`.