product-playbook 1.0.0

package/i18n/en/references/07c-architecture-setup.md

@@ -0,0 +1,197 @@
+# Development Handoff — ARCHITECTURE.md + setup.sh
+
+## 📄 ARCHITECTURE.md Template
+
+```markdown
+# [Product Name] — Technical Architecture
+
+## Directory Structure
+
+[Generate the corresponding directory structure based on the tech stack]
+
+## Database Design
+
+[Consolidate from the PRD's DB Schema — convert to CREATE TABLE SQL or ORM model definitions]
+
+### ER Diagram
+
+[Mermaid erDiagram]
+
+### Key Table Descriptions
+
+| Table | Description | Key Fields | Index Recommendations |
+|-------|------------|------------|----------------------|
+| | | | |
+
+## API Design
+
+[Define RESTful API endpoints or GraphQL schema based on User Stories and feature specs]
+
+### Endpoints List
+
+| Method | Path | Description | Corresponding Task |
+|--------|------|------------|-------------------|
+| GET | /api/v1/[resource] | [Description] | T1.1 |
+| POST | /api/v1/[resource] | [Description] | T1.2 |
+
+### Authentication
+
+[JWT / Session / OAuth, etc.]
+
+## Third-Party Services
+
+| Service | Purpose | Corresponding Feature |
+|---------|---------|----------------------|
+| | | |
+
+## Security Architecture
+
+### CORS Configuration
+
+| Setting | Value | Notes |
+|---------|-------|-------|
+| Allowed Origins | [Production domain, localhost:port] | Do not use wildcard * |
+| Allowed Methods | GET, POST, PUT, DELETE | Based on actual API needs |
+| Allowed Headers | Content-Type, Authorization | |
+| Credentials | true/false | Depends on authentication method |
+
+### Security Headers
+
+[Select applicable headers from references/08-security-checklist.md §5 based on product requirements]
+
+### Rate Limiting Strategy
+
+| Endpoint Type | Limit | Identification Method |
+|--------------|-------|----------------------|
+| General API | [X] req/min | IP + User ID |
+| Login/Register | [X] req/min | IP |
+| File Upload | [X] req/min | User ID |
+
+### Sensitive Data Handling
+
+- Secret management: [.env + platform env vars / Secrets Manager]
+- Logging rules: Never log passwords, tokens, or personal data
+- Data encryption: [TLS in transit / encryption at rest requirements]
+
+> Full security checklist at `references/08-security-checklist.md`
+```
+
+---
+
+## 📄 .gitignore Template
+
+```gitignore
+# Environment variables and secrets
+.env
+.env.local
+.env.*.local
+*.pem
+*.key
+
+# Product planning progress (may contain sensitive business information)
+.product-playbook-progress.md
+
+# IDE and OS
+.idea/
+.vscode/
+*.swp
+.DS_Store
+Thumbs.db
+
+# Dependencies
+node_modules/
+__pycache__/
+*.pyc
+venv/
+
+# Build output
+dist/
+build/
+.next/
+```
+
+---
+
+## 📄 setup.sh Template
+
+```bash
+#!/bin/bash
+# [Product Name] — Project Initialization Script
+# Usage: chmod +x scripts/setup.sh && ./scripts/setup.sh
+
+set -e
+
+echo "🚀 Initializing [Product Name]..."
+
+# ===== Check prerequisites =====
+command -v [node/python/etc] >/dev/null 2>&1 || { echo "❌ [runtime] is required"; exit 1; }
+
+# ===== Install dependencies =====
+echo "📦 Installing dependencies..."
+[npm install / pip install -r requirements.txt / etc]
+
+# ===== Environment setup =====
+if [ ! -f .env ]; then
+  echo "📝 Creating .env file..."
+  cp .env.example .env
+  echo "⚠️  Please edit .env and fill in the required environment variables"
+fi
+
+# ===== Database initialization =====
+echo "🗄️  Initializing database..."
+[migration commands]
+
+echo ""
+echo "✅ Initialization complete!"
+echo ""
+echo "Next steps:"
+echo "  1. Edit .env to fill in environment variables"
+echo "  2. Start the dev server: [start command]"
+echo "  3. Start developing: claude \"Read CLAUDE.md and TASKS.md, then start executing Phase 1\""
+```
+
+---
+
+## User Guidance Text
+
+### In Claude Chat / Cowork
+
+After producing the handoff package, display the following guidance:
+
+```
+📦 Development handoff package is ready! It includes the following files:
+
+  CLAUDE.md        → Claude Code's project memory (product context + tech specs)
+  TASKS.md         → Development task list (4 Phases, [N] Tasks total)
+  TICKETS.md       → Ticket list ([N] tickets, ready to create in Jira/Asana/Linear)
+  docs/PRD.md      → Full PRD
+  docs/ARCHITECTURE.md → Technical architecture (DB schema + API + directory structure)
+  docs/PRODUCT-SPEC.md → Product Spec Summary
+  scripts/setup.sh → One-click initialization script
+
+🔗 How to start developing:
+
+  1. Download and extract to your project folder
+  2. Open a terminal and navigate to the project folder
+  3. Launch Claude Code:
+     $ claude
+  4. Tell Claude Code to begin:
+     > Read CLAUDE.md and TASKS.md, then start executing Phase 0
+
+💡 Tips:
+  - Claude Code automatically reads CLAUDE.md, so it already knows the full product context
+  - After each Phase is complete, it will ask whether to proceed to the next Phase
+  - To adjust feature scope, just edit TASKS.md directly
+  - The "Explicitly Not Doing" list in CLAUDE.md prevents Claude Code from building out of scope
+```
+
+### Pre-Output Final Confirmation
+
+```
+Before producing the development handoff package, I need to confirm a few things:
+
+1. Tech stack: [Confirmed / Needs confirmation]
+2. Product name (for the project folder name): [Confirmed / Needs confirmation]
+3. Any other technical constraints or preferences?
+   - e.g., Must use a specific ORM, need to support specific browsers, existing CI/CD, etc.
+```

package/i18n/en/references/08-security-checklist.md

@@ -0,0 +1,221 @@
+# Security Checklist
+
+> Loaded before producing the development handoff package. Ensures that critical security requirements are considered during the product planning phase, preventing security from becoming an afterthought.
+
+## 🔐 Security Architecture Quick Check
+
+Before producing the development handoff package, verify each of the following security aspects. Mark each as ✅ (covered in planning) or ❌ (needs to be added).
+
+### 1. Authentication & Authorization
+
+```
+| Check Item | Status | Notes |
+|-----------|--------|-------|
+| Authentication method determined (JWT / Session / OAuth / Passkey) | | |
+| Token storage is secure (HttpOnly Cookie, not localStorage) | | |
+| Token expiration and refresh mechanism designed | | |
+| Password storage uses bcrypt / argon2 (not MD5/SHA) | | |
+| Permission model defined (RBAC / ABAC / simple roles) | | |
+| All API endpoints have corresponding authorization checks | | |
+| Login failures have brute-force protection (lockout / progressive delay) | | |
+```
+
+**JWT Best Practices (if using JWT):**
+- Use short-lived Access Tokens (15-30 minutes) + long-lived Refresh Tokens
+- Store Refresh Tokens in HttpOnly Secure Cookies
+- Implement Token Revocation (invalidate Refresh Token on logout)
+- Do not store sensitive information in the JWT payload
+
+### 2. CORS Policy (Cross-Origin Resource Sharing)
+
+```
+| Check Item | Status | Notes |
+|-----------|--------|-------|
+| Allowed Origin list defined (no wildcard *) | | |
+| Only necessary HTTP methods are allowed | | |
+| Access-Control-Allow-Credentials configured | | |
+| Preflight cache duration is reasonable (Access-Control-Max-Age) | | |
+```
+
+**CORS Configuration Template:**
+```
+Allowed Origins:
+  - Production: https://[your-domain.com]
+  - Development: http://localhost:[port]
+
+Allowed Methods: GET, POST, PUT, DELETE, PATCH
+Allowed Headers: Content-Type, Authorization
+Credentials: true (if using cookie-based auth)
+Max-Age: 86400 (24 hours)
+```
+
+### 3. Input Validation & Sanitization
+
+```
+| Check Item | Status | Notes |
+|-----------|--------|-------|
+| All API inputs have server-side validation | | |
+| Parameterized queries used to prevent SQL Injection | | |
+| User input is output-encoded before rendering to HTML (XSS prevention) | | |
+| File uploads have type / size restrictions | | |
+| URL / redirect targets have whitelist validation (Open Redirect prevention) | | |
+```
+
+**Validation Principles:**
+- Frontend validation is UX; backend validation is security — both are needed, but backend validation is non-negotiable
+- Use a Schema Validation Library (e.g., Zod, Joi, Pydantic) for unified validation logic
+- Reject inputs that don't match expected formats — don't try to "fix" user input
+
+### 4. CSRF Protection (Cross-Site Request Forgery)
+
+```
+| Check Item | Status | Notes |
+|-----------|--------|-------|
+| State-changing operations use POST/PUT/DELETE (not GET) | | |
+| CSRF Token implemented or SameSite Cookie used | | |
+| Critical operations have secondary confirmation | | |
+```
+
+### 5. Security Headers
+
+```
+| Header | Purpose | Recommended Value |
+|--------|---------|-------------------|
+| Content-Security-Policy (CSP) | Prevent XSS, data injection | default-src 'self'; script-src 'self' |
+| X-Content-Type-Options | Prevent MIME sniffing | nosniff |
+| X-Frame-Options | Prevent clickjacking | DENY or SAMEORIGIN |
+| Strict-Transport-Security (HSTS) | Enforce HTTPS | max-age=31536000; includeSubDomains |
+| X-XSS-Protection | Browser XSS filter | 0 (relying on CSP is more reliable) |
+| Referrer-Policy | Control referrer information | strict-origin-when-cross-origin |
+| Permissions-Policy | Restrict browser features | camera=(), microphone=(), geolocation=() |
+```
+
+### 6. API Security & Rate Limiting
+
+```
+| Check Item | Status | Notes |
+|-----------|--------|-------|
+| API has global rate limiting (e.g., 100 req/min/IP) | | |
+| Sensitive endpoints have stricter limits (login 5 req/min, register 3 req/min) | | |
+| API error responses don't leak internal details (stack traces, SQL statements) | | |
+| API versioning strategy determined (/api/v1/) | | |
+| Bulk data endpoints have pagination limits | | |
+```
+
+**Rate Limiting Design Recommendations:**
+```
+| Endpoint Type | Recommended Limit | Identification Method |
+|--------------|-------------------|----------------------|
+| General API | 100 req/min | IP + User ID |
+| Login/Register | 5 req/min | IP |
+| Password Reset | 3 req/hour | IP + Email |
+| File Upload | 10 req/min | User ID |
+| Search/Query | 30 req/min | IP + User ID |
+```
+
+### 7. Anti-Scraping & Bot Protection
+
+```
+| Check Item | Status | Notes |
+|-----------|--------|-------|
+| robots.txt configured (restrict sensitive paths) | | |
+| Critical forms have bot protection (reCAPTCHA / hCaptcha / Honeypot) | | |
+| API has User-Agent checks (optional) | | |
+| Sensitive operations have behavioral analysis (optional, advanced) | | |
+```
+
+**Layered Protection Strategy:**
+1. **Basic layer**: Rate Limiting + robots.txt — Every product should have this
+2. **Standard layer**: + CAPTCHA (registration/login) + Honeypot fields — Recommended for B2C products
+3. **Advanced layer**: + Behavioral analysis + IP reputation + Device Fingerprint — High-risk products
+
+### 8. Sensitive Data Protection
+
+```
+| Check Item | Status | Notes |
+|-----------|--------|-------|
+| Sensitive data encrypted in transit (HTTPS/TLS) | | |
+| Sensitive data encrypted at rest (if required) | | |
+| Secrets and keys not stored in code | | |
+| .env and sensitive files added to .gitignore | | |
+| Logs don't record passwords, tokens, credit card numbers, etc. | | |
+| Clear data retention and deletion policy (GDPR if applicable) | | |
+```
+
+**Secrets Management Recommendations:**
+- Development: `.env` file (not in version control) + `.env.example` (key names only, no values)
+- Production: Use platform-provided env var management (Vercel Environment Variables / Railway Variables / AWS Secrets Manager)
+- Never mention secrets in commit messages, PR descriptions, or issues
+
+### 9. .gitignore Security Template
+
+```gitignore
+# Environment variables and secrets
+.env
+.env.local
+.env.*.local
+*.pem
+*.key
+
+# Product planning progress (may contain sensitive business information)
+.product-playbook-progress.md
+
+# IDE and OS
+.idea/
+.vscode/
+*.swp
+.DS_Store
+Thumbs.db
+
+# Dependencies
+node_modules/
+__pycache__/
+*.pyc
+venv/
+
+# Build output
+dist/
+build/
+.next/
+```
+
+---
+
+## 🏷️ OWASP Top 10 Quick Reference
+
+| # | Risk | Relevant to This Product? | Corresponding Check |
+|---|------|--------------------------|-------------------|
+| A01 | Broken Access Control | [Yes/No] | §1 Authentication & Authorization |
+| A02 | Cryptographic Failures | [Yes/No] | §8 Sensitive Data Protection |
+| A03 | Injection (SQL / XSS / Command) | [Yes/No] | §3 Input Validation |
+| A04 | Insecure Design | [Yes/No] | Overall architecture design |
+| A05 | Security Misconfiguration | [Yes/No] | §5 Headers + §2 CORS |
+| A06 | Vulnerable Components | [Yes/No] | Dependency management (npm audit / pip audit) |
+| A07 | Authentication Failures | [Yes/No] | §1 Authentication & Authorization |
+| A08 | Data Integrity Failures | [Yes/No] | §3 Input Validation + §8 Data Protection |
+| A09 | Logging & Monitoring Failures | [Yes/No] | §8 Logging rules |
+| A10 | SSRF (Server-Side Request Forgery) | [Yes/No] | §3 URL whitelist validation |
+
+---
+
+## 📎 Integration Timing
+
+| Trigger | Integration Action |
+|---------|-------------------|
+| Before producing the dev handoff package | Run the security quick check, integrate results into CLAUDE.md "Risk Alerts" and ARCHITECTURE.md "Security Architecture" sections |
+| When producing the PRD | Integrate security check results into PRD §6 "Technical Considerations → Security Requirements" |
+| Pre-mortem step | Prompt the user to consider security failure scenarios |
+| Revision mode S1 | Prompt the user to provide the existing product's current security posture |
+
+## Quality Self-Check
+
+```
+| Check Item | ✅/❌ |
+|-----------|------|
+| Authentication method explicitly chosen, not left as "TBD" | |
+| At least 3 security headers planned | |
+| Rate limiting strategy tailored to product characteristics (not just copied from template) | |
+| .gitignore includes all sensitive files | |
+| All OWASP Top 10 items marked "relevant" have corresponding measures | |
+| Security measure complexity matches the product stage (MVP doesn't need perfect security, but the basics are non-negotiable) | |
+```

package/i18n/en/references/rules-build.md

@@ -0,0 +1,152 @@
+# ⚡ Build Mode Step Sequence (7 Steps + Final Output)
+
+> This file is the authoritative step definition for Build Mode. Loaded by the SKILL.md core dispatcher.
+
+> ⚠️ Required reminder: "Skipping the user research phase means your solution is built on assumptions. We recommend conducting Continuous Discovery as soon as possible after execution to validate."
+
+## Step Sequence
+
+```
+S1. Confirm problem statement (one sentence)
+S2. PR-FAQ → Read references/04a-prfaq.md
+S3. Parallel solutions → Read references/04b-solutions.md → 3.2
+S4. Pre-mortem → Read references/04b-solutions.md → 3.3
+S5. GEM + RICE Prioritization → Read references/04b-solutions.md → 3.4 + 3.5
+S6. MVP + Not Doing List → Read references/04c-mvp.md
+S7. North Star + Aha Moment → Read references/05a-northstar-aha.md
+────
+Final Output → Engineer-oriented execution summary
+```
+
+## Reference Loading Instructions
+
+| Step | Reference File |
+|------|---------------|
+| S1 | No external reference needed (directly guide the user to state the problem) |
+| S2 | `references/04a-prfaq.md` |
+| S3-S5 | `references/04b-solutions.md` |
+| S6 | `references/04c-mvp.md` |
+| S7 | `references/05a-northstar-aha.md` |
+
+## Final Output Format
+
+**Engineer-oriented execution summary**: Solution decisions → MVP boundary → Success metrics → Key risks
+
+After completion, follow `references/rules-end-of-flow.md` to execute the end-of-flow rules.
+
+---
+
+## 🔧 Feature Extension Quick Path (4 Steps)
+
+> Automatically switches to this path when the user is **adding a single feature to an existing product**.
+> Trigger conditions: User description includes phrases like "add a feature," "new feature," "add XX functionality," "on the existing system," "existing product needs," etc.
+
+**Differences from the full Build Mode (7 steps)**: An existing product already has a North Star, Aha Moment, and product positioning — no need to redefine them. A single feature does not require a PR-FAQ press release or full GEM+RICE re-prioritization. The focus is on "what to add, how to add it, and whether it will break existing functionality."
+
+### Feature Extension Step Sequence
+
+```
+S1. Problem + existing system context
+S2. Three parallel solutions + pros/cons + AI recommendation → Read references/04b-solutions.md → 3.2
+S3. Risk assessment (regression + compatibility) → Read references/04b-solutions.md → 3.3
+S4. Execution scope (what to do / what not to touch / acceptance criteria) → Read references/04c-mvp.md
+────
+Final Output → Feature development spec
+```
+
+### S1 Pre-step: Product Context Loading
+
+Before entering S1, read `references/rules-context.md` and check `.product-context.md`:
+
+- **Complete context available (Scenario 1)**: Automatically bring in product name, tech stack, key modules, and the 3 most recent Decision History entries. Change S1 guidance to **confirmation-style**: "Your product is [name], using [tech stack], with key modules including [module list]. What feature do you want to add? Which modules will be affected?" (Questions 2 and part of question 3 are pre-filled — just needs confirmation)
+- **No context (Scenario 2)**: Trigger Context Bootstrap (`rules-context.md` Section 4), then proceed to the standard S1 below
+- **Partial context (Scenario 3)**: Bring in known tech stack and modules (merged from Decision History), and collect the missing parts. For example: "Besides [known modules], are there other modules that might be affected?"
+
+### S1 Guidance Content (Problem + Existing System Context)
+
+Claude needs to collect the following information (guide step by step — do not ask all questions at once. If context has pre-filled some answers, confirm rather than re-collect):
+
+```
+1. What feature do you want to add? What problem does it solve?
+2. Current product architecture overview (tech stack, key modules) ← context can pre-fill
+3. Which existing modules will this feature affect? ← context can partially pre-fill
+4. Is there any user feedback or data supporting this requirement?
+```
+
+### S2 Guidance Content (Three Parallel Solutions + AI Recommendation)
+
+```
+| HMW | Solution A (Conservative / minimal change) | Solution B (Balanced) | Solution C (Bold / refactor) |
+|-----|-------------------------------------------|----------------------|----------------------------|
+| [Problem] | | | |
+
+| Solution | Pros | Cons | Impact Scope | Implementation Complexity |
+|----------|------|------|-------------|--------------------------|
+| A | | | | |
+| B | | | | |
+| C | | | | |
+
+🤖 AI Recommendation: Solution [X]
+Rationale: [Comprehensive judgment based on impact scope, complexity, and risk]
+```
+
+### S3 Guidance Content (Risk Assessment — Focused on Regression & Compatibility)
+
+```
+| Risk Type | Specific Risk | Likelihood | Mitigation |
+|-----------|--------------|------------|------------|
+| Regression risk | [Areas where existing features may be affected] | | |
+| Compatibility risk | [Conflicts with existing architecture/data/APIs] | | |
+| Performance risk | [Impact of the new feature on system performance] | | |
+| Security risk | [Security considerations introduced by the new feature] | | |
+```
+
+### S4 Guidance Content (Execution Scope)
+
+```
+**What to do (Scope)**:
+- [Specific feature items to add]
+- [Existing modules that need modification]
+
+**Do Not Touch**:
+- [Modules and features explicitly not to modify]
+- [Reason for not touching them]
+
+**Acceptance Criteria**:
+- [ ] [Specific testable condition]
+- [ ] [Regression test: confirm existing features are unaffected]
+```
+
+### Feature Extension Final Output Format
+
+**Feature development spec**: Problem statement → Selected solution + rationale → Impact scope → Execution scope + acceptance criteria → Risk list
+
+### Incremental Document Output (when source document is available)
+
+If the user uploaded a source document (PRD, spec, etc.) during the process:
+
+1. **Incremental version** (default when source document exists):
+   - Insert/modify sections in the original document structure
+   - Maintain the original file's format, style, and naming conventions
+   - New content marked with `[NEW]`
+   - Modified content marked with `[UPDATED]` with original preserved as reference
+   - Sections unrelated to the new feature remain completely untouched
+
+2. **Standalone version** (when no source document):
+   - Use the standard Feature development spec format (as defined above)
+
+3. **Ask the user before generating**:
+   "I detected that you uploaded a [document type]. How would you like the output?
+    A) Incremental update on the original document (recommended)
+    B) Standalone feature development spec"
+
+### Reference Loading Instructions
+
+| Step | Reference File |
+|------|---------------|
+| S1 | No external reference needed |
+| S2 | `references/04b-solutions.md` → 3.2 |
+| S3 | `references/04b-solutions.md` → 3.3 |
+| S4 | `references/04c-mvp.md` |
+
+After completion, follow `references/rules-end-of-flow.md` to execute the end-of-flow rules.

package/i18n/en/references/rules-change-propagation.md

@@ -0,0 +1,74 @@
+# 🔄 Change Propagation Rules
+
+> Loaded when the user modifies a previously completed step.
+
+## 📍 Progress Indicator (must be displayed at every step)
+
+When executing any step, Claude must display a progress bar at the very beginning of the response, in this format:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+📍 [Execution Mode] ｜ Progress S[current step number] / S[total steps]
+✅ S1: [Step name] (completed)
+✅ S2: [Step name] (completed)
+▶️ S3: [Step name] (in progress)
+⬜ S4: [Step name] (pending)
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+This progress indicator must appear in the following situations:
+- When entering a new step
+- When the user goes back to a step to make modifications
+- When completing a step and prompting the user for confirmation before moving to the next step
+
+## Trigger Methods
+- "Go back to Persona," "Go back to JTBD," "Go back to HMW," "Go back to PR-FAQ," or any other step name
+- "I want to modify [step name]," "[step name] — I want to change something"
+- Directly referencing an already-produced table or content with "change this to..."
+
+## Required Actions After Modification
+
+When any step is modified, Claude **must proactively perform the following checks**:
+
+```
+Modified Layer               Affected Downstream (must re-confirm or update)
+─────────────────────────────────────────────────────
+Persona / JTBD            → HMW, Opportunity Assessment Table, Positioning, PR-FAQ, North Star, Product Spec Summary
+HMW / Opportunity Assessment → PR-FAQ, Parallel Solutions, MVP, North Star, Product Spec Summary
+Positioning               → PR-FAQ, Product Spec Summary
+PR-FAQ / Solutions        → Pre-mortem, GEM/RICE, MVP, Aha Moment, Product Spec Summary
+MVP / Not Doing List      → User Story, DB schema (if already generated), Product Spec Summary
+North Star / Metrics      → Hypothesis Validation Plan, Product Spec Summary
+Product Spec Summary      → HTML Report, PRD (if already generated)
+```
+
+### Feature Extension dependency:
+```
+Feature Extension dependency:
+─────────────────────────────────────────────────────
+S1 (Problem + Context)  → S2 (Solutions), S3 (Risks), S4 (Execution Scope)
+S2 (Selected Solution)  → S3 (Risks), S4 (Execution Scope)
+S3 (Risk Assessment)    → S4 (Execution Scope)
+```
+
+## Execution Process
+
+1. **Inform the user of the impact scope**: "You modified [step]. This affects [list of downstream steps]. I will update each one."
+2. **Confirm or auto-update downstream items**:
+   - If the downstream change is minor (wording adjustments) → Update directly and explain what changed
+   - If the downstream change is significant (directional shift) → Prompt the user to confirm the new direction before updating
+3. **Re-integrate the Product Spec Summary**
+4. **If an HTML report or PRD has already been generated**: Re-generate it directly and output a version snapshot:
+
+```
+📋 Version Snapshot v[old version] → v[new version]
+Modified step: [Step name]
+Key content before modification: [1-3 sentences]
+Key content after modification: [1-3 sentences]
+Downstream updates triggered: [Which steps were also adjusted]
+```
+
+## Principles
+- No modification happens silently — the impact scope must always be explicitly communicated
+- The user has the right to choose "only modify this step, leave downstream as-is for now." Claude must mark which parts are outdated (add a ⚠️ Needs Update label)
+- Modification history remains traceable within the conversation