TASKS-v0.9.0-rfcs.md — RFC folder structure

Rules for Code

Work on branch: feature/v0.9.0-rfcs
Read CLAUDE.md and STANDARDS.md before starting
All merges require PRs to dev
Code never touches staging or main
Follow Conventional Commits format

Context

DISCOVERY.md is being replaced by RFC-0001 (project kickoff). All discovery and proposals now live in docs/rfcs/ as numbered RFC documents. This aligns with industry-standard RFC/ADR workflow where RFCs are proposals and ADRs are the decisions that come out of them.

Task 1 — Add rfcs/ folder to project creation

Commit: feat: add docs/rfcs/ folder to project structure

File: src/createFolders.ts

Add to the dirs array:

path.join(projectPath, "docs", "rfcs"),

Definition of done: New projects get docs/rfcs/ folder. Build passes.

Task 2 — Remove DISCOVERY.md from sc create

Commit: refactor: remove DISCOVERY.md from project creation

File: src/createDocs.ts

Remove the entire block that copies and fills DISCOVERY.md to docs/. This includes the scale tier checkbox logic, tech stack field filling, and git authorship checkbox logic.

Do NOT delete templates/DISCOVERY.md — keep it for migration compatibility. Add deprecation notice at top:

<!-- DEPRECATED: Replaced by docs/rfcs/RFC-0001-project-kickoff.md in v0.9.0. Kept for migration compatibility. -->

Definition of done: sc create no longer generates DISCOVERY.md. Template file kept with deprecation notice. Build passes.

Task 3 — Create RFC template

Commit: feat: add RFC template for project proposals

Create: templates/rfc-template.md

---
number: [NUMBER]
title: [SHORT TITLE]
status: proposed
authors: [WHO]
date: [DATE]
type: [project-kickoff | module | enhancement | cross-cutting]
related_adrs: []
---

# RFC-[NUMBER]: [SHORT TITLE]

## Summary
[One paragraph — what is being proposed]

## Motivation
[Why do we need this? What problem does it solve?]

## Scope
**In scope:**
[What this RFC covers]

**Out of scope:**
[What this RFC explicitly does not cover]

## Proposed approach
[How should this work? Technical details, data flow, user experience]

## Dependencies
[What other modules/services/RFCs does this depend on? What depends on this?]

## Database impact
[New tables, modified tables, new relationships. Or "None"]

## API impact
[New endpoints, modified endpoints, breaking changes. Or "None"]

## UI impact
[New screens, modified views, user flow changes. Or "None"]

## Risks and edge cases
[What could go wrong? What's hard? What's uncertain?]

## Acceptance criteria
[How do we know this is done and working?]

## Open questions
[What don't we know yet that could affect direction?]

## ADRs produced
_Filled in as decisions are made during review._

Definition of done: RFC template created. Build passes.

Task 4 — Update dry run and documentation

Commit: docs: update dry run and docs for rfcs/ folder

File: src/index.ts — update printDryRun():

Remove DISCOVERY.md from the docs/ tree
Add rfcs/ folder line: │ ├── rfcs/ ← RFC proposals (created during planning)
Keep decisions/ line

File: templates/CLAUDE.md — update folder structure:

Remove DISCOVERY.md from docs/ listing
Add rfcs/ with note: ← RFC proposals and module discovery
Add note: “Project kickoff is RFC-0001, produced by Chat during first planning session”

File: templates/STANDARDS.md — add RFC section after the ADR section:

## Request for Comments (RFC)
All proposals for new features, modules, or significant changes are documented as RFCs in docs/rfcs/.

Naming: RFC-0001-short-description.md (zero-padded, sequential)

Types:
- project-kickoff — Layer 1 discovery, replaces DISCOVERY.md
- module — Layer 2 discovery for a specific feature/module
- enhancement — proposed change to an existing module
- cross-cutting — change that spans multiple modules

Lifecycle:
- proposed — open for discussion
- accepted — approved, ready for build docs (SPEC, ARCHITECTURE, TASKS)
- rejected — not adopted, kept for history
- superseded — replaced by a newer RFC

Enterprise tier: proposed RFCs are submitted as GitHub PRs with the `rfc` label for team review.

RFCs produce ADRs. When a decision is made during RFC review, create an ADR in docs/decisions/ and reference it in the RFC's related_adrs field.

File: templates/PROJECT-INSTRUCTIONS.md — update the Discovery section in the standard block:

Replace references to DISCOVERY.md with RFC-0001
Update Layer 1 description: “Layer 1 — Project kickoff RFC (one session): What is it, who is it for, what scale. Produces RFC-0001. Enough to run sc create.”
Update Layer 2 description: “Layer 2 — Module RFC (per feature): Each module gets its own RFC before planning docs are produced.”

Also update the scaffolder’s own CLAUDE.md at project root with the rfcs/ folder in structure.

Definition of done: All docs reflect rfcs/ folder. DISCOVERY.md references replaced with RFC-0001. Build passes.

Task 5 — Update migration and version references

Commit: chore: update migration for rfcs/ folder and DISCOVERY.md removal

File: Update the v0.8.1-to-v0.9.0 migration in src/migrations/:

Add to filesAdded:

"docs/rfcs/",

Add to filesRemoved (if not already there):

"docs/DISCOVERY.md",

Update instructions to mention RFC replacing DISCOVERY.md.

Update versions.json v0.9.0 changes array — add:

“docs/rfcs/ folder for RFC proposals”
“DISCOVERY.md replaced by RFC-0001 project kickoff”

Update CHANGELOG.md with RFC entries.

PR to dev. Report to operator.

Definition of done: Migration, versions, changelog reflect RFC changes. Build passes.