---
name: Init - Detect and Gather Context
description: Detect documentation type and gather context from request
next_step: step-01-scan.md
---

## STEP 00: Init — Detect Documentation Type and Gather Context

### Purpose

Analyze the user request to identify documentation type, target name, and gather execution context before proceeding to scanning.

### Execution Sequence

#### 1. Type Detection

Analyze the request to identify:

| Clue | → Type |
|------|--------|
| Functional module (SLA, Tickets, Users) | `user` |
| Dev tool (Docker, Postman, VS Code) | `developer` |
| Tables, schema, database | `database` |
| Tests (security, load, E2E) | `testing` |

#### 2. Target Extraction

Identify the specific name:
- **Module:** `sla`, `tickets`, `users`, `permissions`
- **Tool:** `docker`, `postman`, `playwright`, `maildev`
- **Schema:** `support`, `auth`, `nav`, `usr`
- **Test:** `security`, `load`, `e2e`

#### 3. Documentation Mode Detection

Determine if this is:
- **NEW documentation** → Generate from scratch
- **UPDATE documentation** (an "update/refresh" request or drift detected) → Refresh existing content

`update` is a MODE, not a type — re-run with the SAME `--type`; the CLIs are
idempotent and their Zod schemas reject a literal `update` type.

Also capture the **`--tech` flag** (default false): it drives whether step-02
authors the opt-in Section 9 « Référence technique » appendix.

#### 4. Available Developer Tools Reference

| Category | Tools |
|----------|-------|
| Local Environment | Docker Compose, MailDev, VS Code, Environment variables |
| API Testing | Postman, REST Client, Swagger/OpenAPI |
| E2E Testing | Microsoft Playwright, Inspector, Trace Viewer |
| Load Testing | NBomber (.NET), k6, Azure Load Testing |
| Security Testing | OWASP ZAP, Security Code Scan, Snyk, OWASP ASVS |

### Output

At end of this step, you should have:

| Variable | Value | Example |
|----------|-------|---------|
| `type` | user \| developer \| database \| testing | `user` |
| `target` | Module/Tool/Schema name | `users` |
| `application` | Parent app (for user type) | `administration` |
| `mode` | new \| update | `new` |
| `tech` | true when `--tech` was passed (default **false**) — include the Section 9 « Référence technique » appendix | `false` |
| `frontendMode` | source \| client — **read it from step-01's extract-doc report** (`resolved.frontendMode`), never guess | `client` |

> **Deployment modes.** `source` = the SmartStack.app monorepo (docs subsystem
> files in-tree). `client` = a generated project consuming the platform as the
> `@atlashub/smartstack` npm package — routing is PageRegistry-driven and i18n
> goes through moduleResources. **Client projects support ONLY `user`-type
> docs** (DocRenderer is not exported by the package) — if `type` is
> developer/database/testing on a client project, stop and tell the user.

### Success Metrics

- [x] Type correctly identified from request
- [x] Target name extracted and validated
- [x] Application assigned (if type = user)
- [x] Mode determined (new vs update)

### Next Step

→ **step-01-scan.md** — Scan source code and existing documentation based on detected type.