अवधारणाएँ

यह गाइड OpenSpec के पीछे की मुख्य अवधारणाओं और उनके आपसी संबंधों को समझाती है। व्यावहारिक उपयोग के लिए, शुरुआत और कार्यप्रवाह देखें।

दर्शन

OpenSpec चार सिद्धांतों पर आधारित है:

लचीला न कि कठोर         — कोई चरण-बाधा नहीं, अपने काम के अनुसार आगे बढ़ें
चक्रवृद्धि न कि जलधारा  — बनाते समय सीखें, चलते-चलते सुधार करें
सरल न कि जटिल          — हल्का सेटअप, न्यूनतम औपचारिकता
ब्राउनफ़ील्ड-पहले        — मौजूदा कोडबेस के साथ काम करता है, केवल शून्य से शुरू करने वाले प्रोजेक्ट्स के लिए नहीं

इन सिद्धांतों का महत्व

लचीला न कि कठोर। पारंपरिक स्पेक सिस्टम आपको चरणों में बांध देते हैं: पहले आप योजना बनाते हैं, फिर कार्यान्वयन करते हैं, और फिर आप समाप्त हो जाते हैं। OpenSpec अधिक लचीला है — आप अपने काम के लिए उचित क्रम में किसी भी आर्टिफैक्ट को बना सकते हैं।

चक्रवृद्धि न कि जलधारा। आवश्यकताएँ बदलती रहती हैं। समझ गहरी होती जाती है। जो शुरुआत में एक अच्छा दृष्टिकोण लग रहा था, वह कोडबेस देखने के बाद ठहर सकता है या नहीं। OpenSpec इस वास्तविकता को अपनाता है।

सरल न कि जटिल। कुछ स्पेक फ्रेमवर्क विस्तृत सेटअप, कठोर प्रारूपों या भारी प्रक्रियाओं की आवश्यकता होती है। OpenSpec आपके रास्ते में नहीं आता है। सेकंडों में इनिशियलाइज़ करें, तुरंत काम शुरू करें, केवल यदि जरूरत हो तो कस्टमाइज़ करें।

ब्राउनफ़ील्ड-पहले। अधिकांश सॉफ़्टवेयर कार्य शून्य से बनाना नहीं होता — यह मौजूदा प्रणालियों में संशोधन करना होता है। OpenSpec का डेल्टा-आधारित दृष्टिकोण मौजूदा व्यवहार में परिवर्तनों को निर्दिष्ट करना आसान बनाता है, न कि केवल नई प्रणालियों का वर्णन करना।

The Big Picture

OpenSpec आपका काम दो मुख्य क्षेत्रों में संगठित करता है:

┌────────────────────────────────────────────────────────────────────┐
│                        openspec/                                   │
│                                                                    │
│   ┌─────────────────────┐      ┌───────────────────────────────┐   │
│   │       specs/        │      │         changes/              │   │
│   │                     │      │                               │   │
│   │  Source of truth    │◄─────│  Proposed modifications       │   │
│   │  How your system    │ merge│  Each change = one folder     │   │
│   │  currently works    │      │  Contains artifacts + deltas  │   │
│   │                     │      │                               │   │
│   └─────────────────────┘      └───────────────────────────────┘   │
│                                                                    │
└────────────────────────────────────────────────────────────────────┘

Specs सत्य का स्रोत हैं — ये वर्णन करते हैं कि आपका सिस्टम वर्तमान में कैसे व्यवहार करता है।

Changes प्रस्तावित संशोधन हैं — ये अलग-अलग फोल्डर्स में रहते हैं जब तक कि आप उन्हें मर्ज करने के लिए तैयार न हों।

यह अलगाव महत्वपूर्ण है। आप एक साथ कई changes पर काम कर सकते हैं बिना किसी टकराव के। आप किसी change को review कर सकते हैं जब तक कि वह मुख्य specs को प्रभावित न करे। और जब आप किसी change को archive करते हैं, तो उसके deltas सत्य के स्रोत में स्वच्छता से मर्ज हो जाते हैं。

Specs

Specs संरचित आवश्यकताओं और परिदृश्यों का उपयोग करके आपके सिस्टम के व्यवहार का वर्णन करते हैं।

Structure

openspec/specs/
├── auth/
│   └── spec.md           # Authentication behavior
├── payments/
│   └── spec.md           # Payment processing
├── notifications/
│   └── spec.md           # Notification system
└── ui/
    └── spec.md           # UI behavior and themes

Specs को domain के अनुसार संगठित करें — आपके सिस्टम के लिए तर्कसंगत समूहन। सामान्य पैटर्न:

Feature area के अनुसार: auth/, payments/, search/
Component के अनुसार: api/, frontend/, workers/
Bounded context के अनुसार: ordering/, fulfillment/, inventory/

Spec Format

एक spec में आवश्यकताएँ होती हैं, और प्रत्येक आवश्यकता के परिदृश्य होते हैं:

markdown

# Auth Specification

## Purpose
Authentication and session management for the application.

## Requirements

### Requirement: User Authentication
The system SHALL issue a JWT token upon successful login.

#### Scenario: Valid credentials
- GIVEN a user with valid credentials
- WHEN the user submits login form
- THEN a JWT token is returned
- AND the user is redirected to dashboard

#### Scenario: Invalid credentials
- GIVEN invalid credentials
- WHEN the user submits login form
- THEN an error message is displayed
- AND no token is issued

### Requirement: Session Expiration
The system MUST expire sessions after 30 minutes of inactivity.

#### Scenario: Idle timeout
- GIVEN an authenticated session
- WHEN 30 minutes pass without activity
- THEN the session is invalidated
- AND the user must re-authenticate

मुख्य तत्व:

Element	Purpose
`## Purpose`	इस spec के domain का उच्च-स्तरीय वर्णन
`### Requirement:`	एक विशिष्ट व्यवहार जो सिस्टम में होना चाहिए
`#### Scenario:`	आवश्यकता के क्रियान्वयन का एक विशिष्ट उदाहरण
SHALL/MUST/SHOULD	RFC 2119 कीवर्ड जो आवश्यकता की तीव्रता संकेतित करते हैं

Specs को इस तरह संरचित क्यों करें

आवश्यकताएँ "क्या" हैं — ये बताती हैं कि सिस्टम को क्या करना चाहिए, बिना implementation निर्दिष्ट किए।

परिदृश्य "कब" हैं — ये सत्यापित किए जा सकने वाले विशिष्ट उदाहरण प्रदान करते हैं। अच्छे परिदृश्य:

परीक्षण योग्य होते हैं (आप उनके लिए स्वचालित परीक्षण लिख सकते हैं)
दोनों happy path और edge cases को कवर करते हैं
Given/When/Then या समान संरचित प्रारूप का उपयोग करते हैं

RFC 2119 कीवर्ड (SHALL, MUST, SHOULD, MAY) इरादा संचारित करते हैं:

MUST/SHALL — निरपेक्ष आवश्यकता
SHOULD — अनुशंसित, लेकिन अपवाद मौजूद हैं
MAY — वैकल्पिक

Spec क्या है (और क्या नहीं है)

एक spec एक व्यवहार अनुबंध है, implementation योजना नहीं।

अच्छा spec सामग्री:

प्रेक्षणीय व्यवहार जिस पर उपयोगकर्ता या downstream सिस्टम निर्भर करते हैं
इनपुट, आउटपुट और त्रुटि स्थितियाँ
बाहरी प्रतिबंध (सुरक्षा, गोपनीयता, विश्वसनीयता, संगतता)
परिदृश्य जिन्हें परीक्षण या स्पष्ट रूप से सत्यापित किया जा सकता है

Specs में से बचें:

आंतरिक class/function नाम
Library या framework चयन
चरण-दर-चरण implementation विवरण
विस्तृत execution योजनाएँ (ये design.md या tasks.md में आती हैं)

त्वरित परीक्षण:

यदि implementation बदल सकता है बिना बाहरी रूप से दृश्य व्यवहार बदले, तो यह संभवतः spec में नहीं आना चाहिए।

हल्का रखें: प्रगतिशील कठोरता

OpenSpec का लक्ष्य бюроक्रेसी से बचना है। सबसे हल्का स्तर उपयोग करें जो change को सत्यापनीय बनाए रखे।

Lite spec (डिफ़ॉल्ट):

छोटे व्यवहार-पहले आवश्यकताएँ
स्पष्ट scope और non-goals
कुछ विशिष्ट स्वीकृति जाँचें

Full spec (उच्च जोखिम के लिए):

Cross-team या cross-repo changes
API/contract changes, migrations, security/privacy चिंताएँ
Changes जहाँ अस्पष्टता महँगी पुनर्निर्माण का कारण बन सकती है

अधिकांश changes Lite मोड में रहने चाहिए।

मानव + एजेंट सहयोग

अनेक टीमों में, मानव अन्वेषण करते हैं और एजेंट artifacts तैयार करते हैं। प्रस्तावित लूप है:

मानव इरादा, संदर्भ और प्रतिबंध प्रदान करता है।
एजेंट इसे व्यवहार-पहले आवश्यकताओं और परिदृश्यों में रूपांतरित करता है।
एजेंट implementation विवरण को design.md और tasks.md में रखता है, spec.md में नहीं।
सत्यापन implementation से पहले संरचना और स्पष्टता की पुष्टि करता है।

यह specs को मानवों के लिए पठनीय और एजेंटों के लिए सुसंगत रखता है।

Changes

एक change आपके सिस्टम में प्रस्तावित संशोधन है, जो एक फोल्डर के रूप में पैकेज किया गया है जिसमें इसे समझने और क्रियान्वित करने के लिए आवश्यक सब कुछ शामिल है।

Change Structure

openspec/changes/add-dark-mode/
├── proposal.md           # Why and what
├── design.md             # How (technical approach)
├── tasks.md              # Implementation checklist
├── .openspec.yaml        # Change metadata (optional): schema, created, skip_specs, retire_capabilities
└── specs/                # Delta specs
    └── ui/
        └── spec.md       # What's changing in ui/spec.md

प्रत्येक change स्वयं-संपूर्ण है। इसमें है:

Artifacts — दस्तावेज़ जो इरादा, डिज़ाइन और कार्य पकड़ते हैं
Delta specs — जो जोड़ा, संशोधित या हटाया जा रहा है उसके लिए specifications
Metadata — इस विशिष्ट change के लिए वैकल्पिक कॉन्फ़िगरेशन

Changes फोल्डर क्यों हैं

एक change को फोल्डर के रूप में पैकेज करने के कई लाभ हैं:

सब कुछ एक साथ。 Proposal, design, tasks और specs एक ही जगह रहते हैं। अलग-अलग स्थानों में खोजने की ज़रूरत नहीं।
समांतर कार्य。 कई changes एक साथ मौजूद हो सकते हैं बिना टकराए। add-dark-mode पर काम करें जबकि fix-auth-bug भी प्रगति में है।
स्वच्छ इतिहास。 Archive होने पर, changes अपने पूरे संदर्भ के साथ changes/archive/ में चले जाते हैं। आप वापस देख सकते हैं और समझ सकते हैं न केवल क्या बदला, बल्कि क्यों।
Review-अनुकूल。 एक change फोल्डर review करना आसान है — खोलें, proposal पढ़ें, design जाँचें, spec deltas देखें।

Artifacts

Artifacts change के भीतर दस्तावेज़ हैं जो कार्य का मार्गदर्शन करते हैं।

The Artifact Flow

proposal ──────► specs ──────► design ──────► tasks ──────► implement
    │               │             │              │
   why            what           how          steps
 + scope        changes       approach      to take

Artifacts एक-दूसरे पर निर्भर करते हैं। प्रत्येक artifact अगले के लिए संदर्भ प्रदान करता है।

Artifact Types

Proposal (`proposal.md`)

Proposal इरादा, scope और approach को उच्च स्तर पर पकड़ता है।

markdown

# Proposal: Add Dark Mode

## Intent
Users have requested a dark mode option to reduce eye strain
during nighttime usage and match system preferences.

## Scope
In scope:
- Theme toggle in settings
- System preference detection
- Persist preference in localStorage

Out of scope:
- Custom color themes (future work)
- Per-page theme overrides

## Approach
Use CSS custom properties for theming with a React context
for state management. Detect system preference on first load,
allow manual override.

Proposal कब अपडेट करें:

Scope बदलता है (संकीर्ण या विस्तारित)
इरादा स्पष्ट होता है (समस्या का बेहतर समझ)
Approach मूलभूत रूप से बदलता है

Specs (delta specs in `specs/`)

Delta specs वर्तमान specs के सापेक्ष क्या बदल रहा है का वर्णन करते हैं। नीचे Delta Specs देखें।

Design (`design.md`)

Design तकनीकी दृष्टिकोण और आर्किटेक्चर निर्णय पकड़ता है।

markdown

# Design: Add Dark Mode

## Technical Approach
Theme state managed via React Context to avoid prop drilling.
CSS custom properties enable runtime switching without class toggling.

## Architecture Decisions

### Decision: Context over Redux
Using React Context for theme state because:
- Simple binary state (light/dark)
- No complex state transitions
- Avoids adding Redux dependency

### Decision: CSS Custom Properties
Using CSS variables instead of CSS-in-JS because:
- Works with existing stylesheet
- No runtime overhead
- Browser-native solution

## Data Flow
```
ThemeProvider (context)
       │
       ▼
ThemeToggle ◄──► localStorage
       │
       ▼
CSS Variables (applied to :root)
```

## File Changes
- `src/contexts/ThemeContext.tsx` (new)
- `src/components/ThemeToggle.tsx` (new)
- `src/styles/globals.css` (modified)

Design कब अपडेट करें:

Implementation से पता चलता है कि दृष्टिकोण काम नहीं करेगा
बेहतर समाधान खोजा जाता है
निर्भरताएँ या प्रतिबंध बदलते हैं

Tasks (`tasks.md`)

Tasks implementation checklist हैं — checkbox के साथ विशिष्ट चरण।

markdown

# Tasks

## 1. Theme Infrastructure
- [ ] 1.1 Create ThemeContext with light/dark state
- [ ] 1.2 Add CSS custom properties for colors
- [ ] 1.3 Implement localStorage persistence
- [ ] 1.4 Add system preference detection

## 2. UI Components
- [ ] 2.1 Create ThemeToggle component
- [ ] 2.2 Add toggle to settings page
- [ ] 2.3 Update Header to include quick toggle

## 3. Styling
- [ ] 3.1 Define dark theme color palette
- [ ] 3.2 Update components to use CSS variables
- [ ] 3.3 Test contrast ratios for accessibility

कार्य सर्वोत्तम प्रथाएँ:

संबंधित कार्य शीर्षकों के अंतर्गत समूहीकृत करें
पदानुक्रमित क्रमांकन का उपयोग करें (1.1, 1.2, आदि)
कार्य इतने छोटे रखें कि एक सत्र में पूरा किए जा सकें
पूरा करने पर कार्य पर टिक लगाएँ

Delta Specs

Delta specs वह मुख्य अवधारणा है जो OpenSpec को brownfield development के लिए काम करती है। ये क्या बदल रहा है का वर्णन करते हैं, पूरे spec को दोहराए बिना।

The Format

markdown

# Delta for Auth

## ADDED Requirements

### Requirement: Two-Factor Authentication
The system MUST support TOTP-based two-factor authentication.

#### Scenario: 2FA enrollment
- GIVEN a user without 2FA enabled
- WHEN the user enables 2FA in settings
- THEN a QR code is displayed for authenticator app setup
- AND the user must verify with a code before activation

#### Scenario: 2FA login
- GIVEN a user with 2FA enabled
- WHEN the user submits valid credentials
- THEN an OTP challenge is presented
- AND login completes only after valid OTP

## MODIFIED Requirements

### Requirement: Session Expiration
The system MUST expire sessions after 15 minutes of inactivity.
(Previously: 30 minutes)

#### Scenario: Idle timeout
- GIVEN an authenticated session
- WHEN 15 minutes pass without activity
- THEN the session is invalidated

## REMOVED Requirements

### Requirement: Remember Me
(Deprecated in favor of 2FA. Users should re-authenticate each session.)

Delta Sections

Section	Meaning	What Happens on Archive
`## ADDED Requirements`	नया व्यवहार	मुख्य spec में जोड़ा जाता है
`## MODIFIED Requirements`	परिवर्तित व्यवहार	मौजूदा आवश्यकता को बदलता है
`## REMOVED Requirements`	अनुचित व्यवहार	मुख्य spec से हटाया जाता है; अंतिम आवश्यकता हटाना capability को निष्क्रिय करता है और उसका spec फ़ाइल हटाता है, जब change `retire_capabilities: true` घोषित करता है
`## Purpose`	एक नई capability का उद्देश्य	बनाए जा रहे मुख्य spec का Purpose seed करता है; spec पहले से मौजूद हो तो अनदेखा किया जाता है

Delta क्यों, पूरे Specs की बजाय

स्पष्टता। Delta ठीक-ठीक दिखाता है कि क्या बदल रहा है। पूरा spec पढ़ने पर, आपको वर्तमान संस्करण के विरुद्ध मानसिक रूप से diff करना पड़ता।

टकराव से बचाव। दो changes एक ही spec फ़ाइल को छू सकते हैं बिना टकराए, बशर्ते वे अलग-अलग आवश्यकताओं को संशोधित करें।

Review दक्षता। समीक्षक बदलाव देखते हैं, अपरिवर्तित संदर्भ नहीं। जो महत्वपूर्ण है उस पर ध्यान केंद्रित करें।

Brownfield अनुकूलता। अधिकांश कार्य मौजूदा व्यवहार को संशोधित करते हैं。 Deltas संशोधनों को प्रथम-श्रेणी बनाते हैं, एक बाद में सोची गई बात नहीं।

Schemas

Schemas किसी workflow के लिए artifact types और उनके dependencies को define करते हैं।

Schemas कैसे काम करते हैं

yaml

# openspec/schemas/spec-driven/schema.yaml
name: spec-driven
artifacts:
  - id: proposal
    generates: proposal.md
    requires: []              # No dependencies, can create first

  - id: specs
    generates: specs/**/*.md
    requires: [proposal]      # Needs proposal before creating

  - id: design
    generates: design.md
    requires: [proposal]      # Can create in parallel with specs

  - id: tasks
    generates: tasks.md
    requires: [specs, design] # Needs both specs and design first

Artifacts एक dependency graph बनाते हैं:

                    proposal
                   (root node)
                       │
         ┌─────────────┴─────────────┐
         │                           │
         ▼                           ▼
      specs                       design
   (requires:                  (requires:
    proposal)                   proposal)
         │                           │
         └─────────────┬─────────────┘
                       │
                       ▼
                    tasks
                (requires:
                specs, design)

Dependencies enablers हैं, gates नहीं। ये दिखाते हैं कि क्या बनाना संभव है, यह नहीं कि आपको अगला क्या बनाना चाहिए। यदि आपको design की ज़रूरत नहीं है तो आप उसे skip कर सकते हैं。आप specs को design से पहले या बाद में बना सकते हैं — दोनों केवल proposal पर निर्भर करते हैं।

Built-in Schemas

spec-driven (default)

Spec-driven development के लिए मानक workflow:

proposal → specs → design → tasks → implement

सबसे अच्छा उपयोग: उन feature work के लिए जहाँ आप implementation से पहले specs पर सहमत होना चाहते हैं।

Custom Schemas

अपनी टीम के workflow के लिए custom schemas बनाएं:

bash

# Create from scratch
openspec schema init research-first

# Or fork an existing one
openspec schema fork spec-driven research-first

Custom schema का उदाहरण:

yaml

# openspec/schemas/research-first/schema.yaml
name: research-first
artifacts:
  - id: research
    generates: research.md
    requires: []           # Do research first

  - id: proposal
    generates: proposal.md
    requires: [research]   # Proposal informed by research

  - id: tasks
    generates: tasks.md
    requires: [proposal]   # Skip specs/design, go straight to tasks

Custom schemas बनाने और उपयोग करने की पूरी जानकारी के लिए Customization देखें।

सब कुछ कैसे जुड़ता है

┌──────────────────────────────────────────────────────────────────────────────┐
│                              OPENSPEC FLOW                                   │
│                                                                              │
│   ┌────────────────┐                                                         │
│   │  1. START      │  /opsx:propose (core) or /opsx:new (expanded)           │
│   │     CHANGE     │                                                         │
│   └───────┬────────┘                                                         │
│           │                                                                  │
│           ▼                                                                  │
│   ┌────────────────┐                                                         │
│   │  2. CREATE     │  /opsx:ff or /opsx:continue (expanded workflow)         │
│   │     ARTIFACTS  │  Creates proposal → specs → design → tasks              │
│   │                │  (based on schema dependencies)                         │
│   └───────┬────────┘                                                         │
│           │                                                                  │
│           ▼                                                                  │
│   ┌────────────────┐                                                         │
│   │  3. IMPLEMENT  │  /opsx:apply                                            │
│   │     TASKS      │  Work through tasks, checking them off                  │
│   │                │◄──── Update artifacts as you learn                      │
│   └───────┬────────┘                                                         │
│           │                                                                  │
│           ▼                                                                  │
│   ┌────────────────┐                                                         │
│   │  4. VERIFY     │  /opsx:verify (optional)                                │
│   │     WORK       │  Check implementation matches specs                     │
│   └───────┬────────┘                                                         │
│           │                                                                  │
│           ▼                                                                  │
│   ┌────────────────┐     ┌──────────────────────────────────────────────┐    │
│   │  5. ARCHIVE    │────►│  Delta specs merge into main specs           │    │
│   │     CHANGE     │     │  Change folder moves to archive/             │    │
│   └────────────────┘     │  Specs are now the updated source of truth   │    │
│                          └──────────────────────────────────────────────┘    │
│                                                                              │
└──────────────────────────────────────────────────────────────────────────────┘

वर्चुअस cycle:

Specs वर्तमान behavior का वर्णन करते हैं
Changes modifications प्रस्तावित करते हैं (deltas के रूप में)
Implementation बदलावों को वास्तविक बनाता है
Archive deltas को specs में merge करता है
Specs अब नया behavior वर्णन करते हैं
अगला change updated specs पर आधारित होता है

Glossary

Term	Definition
Artifact	Change के भीतर एक document (proposal, design, tasks, या delta specs)
Archive	Change को पूरा करने और उसके deltas को main specs में merge करने की प्रक्रिया
Change	System में प्रस्तावित modification, जो artifacts के साथ folder के रूप में packaged है
Delta spec	एक spec जो वर्तमान specs के सापेक्ष बदलावों (ADDED/MODIFIED/REMOVED) का वर्णन करता है
Domain	Specs के लिए logical grouping (जैसे `auth/`, `payments/`)
Requirement	एक विशिष्ट behavior जो system में होना चाहिए
Scenario	Requirement का एक concrete example, आमतौर पर Given/When/Then format में
Schema	Artifact types और उनके dependencies की definition
Spec	System behavior का वर्णन करने वाला specification, जिसमें requirements और scenarios शामिल हैं
Source of truth	`openspec/specs/` directory, जिसमें वर्तमान सहमत behavior शामिल है

Next Steps

Getting Started - व्यावहारिक प्रारंभिक कदम
Workflows - सामान्य patterns और कब प्रत्येक का उपयोग करें
Commands - पूर्ण command reference
Customization - Custom schemas बनाएं और अपना project configure करें

अवधारणाएँ

दर्शन

इन सिद्धांतों का महत्व

The Big Picture

Specs

Structure

Spec Format

Specs को इस तरह संरचित क्यों करें

Spec क्या है (और क्या नहीं है)

हल्का रखें: प्रगतिशील कठोरता

मानव + एजेंट सहयोग

Changes

Change Structure

Changes फोल्डर क्यों हैं

Artifacts

The Artifact Flow

Artifact Types

Proposal (`proposal.md`)

Specs (delta specs in `specs/`)

Design (`design.md`)

Tasks (`tasks.md`)

Delta Specs

The Format

Delta Sections

Delta क्यों, पूरे Specs की बजाय

Schemas

Schemas कैसे काम करते हैं

Built-in Schemas

Custom Schemas

Archive

Archive करने पर क्या होता है

Archive Process

Archive क्यों महत्वपूर्ण है

सब कुछ कैसे जुड़ता है

Glossary

Next Steps

अवधारणाएँ ​

दर्शन ​

इन सिद्धांतों का महत्व ​

The Big Picture ​

Specs ​

Structure ​

Spec Format ​

Specs को इस तरह संरचित क्यों करें ​

Spec क्या है (और क्या नहीं है) ​

हल्का रखें: प्रगतिशील कठोरता ​

मानव + एजेंट सहयोग ​

Changes ​

Change Structure ​

Changes फोल्डर क्यों हैं ​

Artifacts ​

The Artifact Flow ​

Artifact Types ​

Proposal (proposal.md) ​

Specs (delta specs in specs/) ​

Design (design.md) ​

Tasks (tasks.md) ​

Delta Specs ​

The Format ​

Delta Sections ​

Delta क्यों, पूरे Specs की बजाय ​

Schemas ​

Schemas कैसे काम करते हैं ​

Built-in Schemas ​

Custom Schemas ​

Archive ​

Archive करने पर क्या होता है ​

Archive Process ​

Archive क्यों महत्वपूर्ण है ​

सब कुछ कैसे जुड़ता है ​

Glossary ​

Next Steps ​

अवधारणाएँ

दर्शन

इन सिद्धांतों का महत्व

The Big Picture

Specs

Structure

Spec Format

Specs को इस तरह संरचित क्यों करें

Spec क्या है (और क्या नहीं है)

हल्का रखें: प्रगतिशील कठोरता

मानव + एजेंट सहयोग

Changes

Change Structure

Changes फोल्डर क्यों हैं

Artifacts

The Artifact Flow

Artifact Types

Proposal (`proposal.md`)

Specs (delta specs in `specs/`)

Design (`design.md`)

Tasks (`tasks.md`)

Delta Specs

The Format

Delta Sections

Delta क्यों, पूरे Specs की बजाय

Schemas

Schemas कैसे काम करते हैं

Built-in Schemas

Custom Schemas

Archive

Archive करने पर क्या होता है

Archive Process

Archive क्यों महत्वपूर्ण है

सब कुछ कैसे जुड़ता है

Glossary

Next Steps