universal-dev-standards 4.2.0 → 5.0.0-beta.10

package/bundled/core/requirement-engineering.md

@@ -0,0 +1,39 @@
+# Requirement Engineering Standards
+
+**Version**: 1.0.0
+**Last Updated**: 2026-01-28
+**Applicability**: All software projects
+**Scope**: universal
+**Industry Standards**: IEEE 830-1998, IEEE 29148-2018, SWEBOK v4.0
+**References**: [computer.org](https://www.computer.org/education/bodies-of-knowledge/software-engineering/v4)
+
+---
+
+## Summary
+
+Requirements Engineering is the systematic process of eliciting, analyzing, specifying, and validating software requirements throughout the development lifecycle. It provides the theoretical foundation for writing, managing, and validating requirements based on industry standards including IEEE 830-1998, IEEE 29148-2018, SWEBOK v4.0, and ISO/IEC 25010.
+
+The process encompasses Functional Requirements (what the system should DO), Non-Functional Requirements (quality attributes like performance, security, usability), and Constraints. User Stories (Agile format) with Acceptance Criteria (Given-When-Then) serve as the primary specification format, validated through INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable).
+
+---
+
+**Full Guide: [Requirement Engineering Guide](../methodologies/guides/requirement-engineering-guide.md)**
+
+---
+
+## Quick Reference
+
+| Aspect | Description |
+|--------|-------------|
+| **Core Process** | Elicitation → Analysis → Specification → Validation |
+| **Requirement Types** | Functional (FR), Non-Functional (NFR), Constraints |
+| **Prioritization** | MoSCoW, P0-P3, Kano Model |
+| **Quality Model** | ISO/IEC 25010 (8 characteristics) |
+| **Standards** | IEEE 830, IEEE 29148, SWEBOK v4.0 |
+
+## Related Standards
+
+- [Spec-Driven Development](spec-driven-development.md)
+- [Forward Derivation Standards](forward-derivation-standards.md)
+- [Behavior-Driven Development](behavior-driven-development.md)
+- [Testing Standards](testing-standards.md)

package/bundled/core/reverse-engineering-standards.md

@@ -3,6 +3,8 @@
 **Version**: 1.0.0
 **Last Updated**: 2026-01-19
 **Applicability**: All projects requiring code-to-specification transformation
+**Scope**: uds-specific
+**Industry Standards**: IEEE 830-1998, SWEBOK v4.0 Chapter 9
 
 > **Language**: [English](../core/reverse-engineering-standards.md) | [繁體中文](../locales/zh-TW/core/reverse-engineering-standards.md)
 
@@ -359,10 +361,10 @@ Use reverse-engineered specifications to identify test coverage gaps:
 
 ### Skill References
 
-- [Reverse Engineer Skill](../skills/claude-code/reverse-engineer/SKILL.md) - Detailed workflow implementation
-- [Spec-Driven Development Skill](../skills/claude-code/spec-driven-dev/SKILL.md) - SDD integration
-- [BDD Assistant Skill](../skills/claude-code/bdd-assistant/SKILL.md) - Gherkin formulation
-- [TDD Assistant Skill](../skills/claude-code/tdd-assistant/SKILL.md) - Test coverage analysis
+- [Reverse Engineer Skill](../skills/reverse-engineer/SKILL.md) - Detailed workflow implementation
+- [Spec-Driven Development Skill](../skills/spec-driven-dev/SKILL.md) - SDD integration
+- [BDD Assistant Skill](../skills/bdd-assistant/SKILL.md) - Gherkin formulation
+- [TDD Assistant Skill](../skills/tdd-assistant/SKILL.md) - Test coverage analysis
 
 ---
 

package/bundled/core/security-standards.md

@@ -0,0 +1,244 @@
+# Security Standards
+
+> **Language**: English | [繁體中文](../locales/zh-TW/core/security-standards.md)
+
+**Version**: 1.1.0
+**Last Updated**: 2026-01-29
+**Applicability**: All software projects
+**Scope**: universal
+**Industry Standards**: OWASP Top 10 (2021), OWASP ASVS v4.0, NIST SP 800-53
+**References**: [owasp.org](https://owasp.org/Top10/), [owasp.org](https://owasp.org/www-project-application-security-verification-standard/)
+
+> **For detailed explanations and examples, see [Security Guide](guides/security-guide.md)**
+
+---
+
+## Purpose
+
+This standard defines comprehensive security guidelines for software development, covering secure coding practices, vulnerability prevention, authentication/authorization, and security testing.
+
+**Reference Standards**:
+- [OWASP Top 10 (2021)](https://owasp.org/Top10/)
+- [OWASP ASVS v4.0](https://owasp.org/www-project-application-security-verification-standard/)
+- [NIST SP 800-53](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)
+
+---
+
+## Core Security Principles
+
+| Principle | Implementation |
+|-----------|----------------|
+| **Least Privilege** | Role-based access, time-limited tokens |
+| **Fail Securely** | Deny access on auth error, don't expose stack traces |
+| **Separation of Duties** | Different roles for dev/deploy/admin |
+| **Defense in Depth** | Don't rely on single control |
+| **Security by Default** | Secure defaults, opt-in for less secure options |
+| **Zero Trust** | Verify every request, assume breach |
+
+---
+
+## OWASP Top 10 Prevention Checklist
+
+| Vulnerability | Prevention |
+|---------------|------------|
+| **A01: Broken Access Control** | Deny by default, server-side checks, validate ownership |
+| **A02: Cryptographic Failures** | Encrypt PII, use TLS 1.3, use secrets management |
+| **A03: Injection** | Parameterized queries, validated input, use ORMs |
+| **A04: Insecure Design** | Threat modeling, security requirements in specs |
+| **A05: Security Misconfiguration** | Remove defaults, disable unused features, security headers |
+| **A06: Vulnerable Components** | Maintain SBOM, scan with npm audit/Snyk, patch quickly |
+| **A07: Auth Failures** | Strong passwords, MFA, secure sessions |
+| **A08: Integrity Failures** | Code signing, verify checksums, secure CI/CD |
+| **A09: Logging Failures** | Log security events, protect log integrity |
+| **A10: SSRF** | Allowlist URLs, block internal IPs |
+
+---
+
+## Required Security Headers
+
+```http
+Content-Security-Policy: default-src 'self'; script-src 'self'
+X-Content-Type-Options: nosniff
+X-Frame-Options: DENY
+Strict-Transport-Security: max-age=31536000; includeSubDomains
+X-XSS-Protection: 0
+Referrer-Policy: strict-origin-when-cross-origin
+Permissions-Policy: geolocation=(), camera=(), microphone=()
+```
+
+---
+
+## Cryptography Requirements
+
+### Algorithm Selection
+
+| Purpose | Required | Avoid |
+|---------|----------|-------|
+| **Symmetric Encryption** | AES-256-GCM | DES, 3DES, AES-ECB |
+| **Asymmetric Encryption** | RSA-2048+, ECDSA P-256+ | RSA-1024 |
+| **Hashing** | SHA-256, SHA-3, BLAKE3 | MD5, SHA-1 |
+| **Password Hashing** | Argon2id, bcrypt, scrypt | SHA-256, PBKDF2 |
+| **TLS Version** | TLS 1.3, TLS 1.2 | TLS 1.0, TLS 1.1, SSL |
+
+### Password Hashing Configuration
+
+| Algorithm | Configuration |
+|-----------|---------------|
+| **Argon2id** | Memory: 64 MB, Iterations: 3, Parallelism: 4, Salt: 16 bytes |
+| **bcrypt** | Cost factor ≥ 12 |
+| **scrypt** | N=2^17, r=8, p=1 |
+
+---
+
+## Authentication Requirements
+
+### Password Policy
+
+| Requirement | Minimum | Recommended |
+|-------------|---------|-------------|
+| **Length** | 8 characters | 12+ characters |
+| **Breached Password Check** | Required | HaveIBeenPwned API |
+| **History** | Last 5 passwords | Last 10 passwords |
+
+### Session Management
+
+| Parameter | Recommended Value |
+|-----------|-------------------|
+| **Session ID Length** | ≥ 128 bits |
+| **Session Timeout (idle)** | 15-30 minutes |
+| **Session Timeout (absolute)** | 8-24 hours |
+| **Cookie Flags** | `Secure; HttpOnly; SameSite=Strict` |
+
+### MFA Requirements
+
+- **Required for**: Admin access, sensitive operations, account recovery
+- **Recommended for**: All user accounts
+- **Preferred**: WebAuthn (phishing resistant)
+
+---
+
+## Authorization Checklist
+
+- [ ] Implement authorization on server-side (never trust client)
+- [ ] Check permissions on every request
+- [ ] Use deny by default
+- [ ] Log authorization failures
+- [ ] Implement rate limiting per user/role
+- [ ] Review permissions periodically
+
+---
+
+## Input Validation Rules
+
+| Data Type | Validation |
+|-----------|------------|
+| **Email** | RFC 5322 regex + domain check |
+| **URL** | Protocol allowlist, no internal IPs |
+| **Phone** | E.164 format |
+| **Date** | ISO 8601, reasonable range |
+| **Integer** | Type check, min/max bounds |
+| **String** | Length limits, character allowlist |
+| **File** | Type, size, magic bytes |
+
+---
+
+## API Security Requirements
+
+### Rate Limiting
+
+| Endpoint Type | Limit | Window |
+|---------------|-------|--------|
+| **Login** | 5 attempts | 15 minutes |
+| **API (authenticated)** | 1000 requests | 1 hour |
+| **API (unauthenticated)** | 100 requests | 1 hour |
+| **Password reset** | 3 requests | 1 hour |
+
+---
+
+## Security Testing Requirements
+
+| Test Type | Frequency | Purpose |
+|-----------|-----------|---------|
+| **SAST** | Every commit | Find vulnerabilities in source code |
+| **DAST** | Weekly/Release | Test running application |
+| **SCA** | Daily | Check dependency vulnerabilities |
+| **Penetration Testing** | Quarterly/Annually | Manual security testing |
+| **Security Code Review** | Critical changes | Manual code review |
+
+### Recommended Tools
+
+| Category | Tools |
+|----------|-------|
+| **SAST** | SonarQube, Semgrep, CodeQL |
+| **DAST** | OWASP ZAP, Burp Suite |
+| **SCA** | Snyk, npm audit, Dependabot |
+| **Secrets Scanning** | GitLeaks, TruffleHog |
+
+---
+
+## Incident Response Severity
+
+| Level | Description | Response Time |
+|-------|-------------|---------------|
+| **P1 Critical** | Active breach, data exfiltration | < 15 min |
+| **P2 High** | Vulnerability exploited, no data loss | < 1 hour |
+| **P3 Medium** | Vulnerability discovered, not exploited | < 24 hours |
+| **P4 Low** | Minor security issue | < 1 week |
+
+---
+
+## Pre-Deployment Security Checklist
+
+### Authentication & Authorization
+- [ ] Passwords hashed with Argon2id/bcrypt
+- [ ] MFA available for all users
+- [ ] Session management secure (HttpOnly, Secure, SameSite)
+- [ ] Authorization checked server-side on every request
+
+### Input/Output
+- [ ] All input validated server-side
+- [ ] Output encoded for context (HTML, JS, URL)
+- [ ] Parameterized queries for all database operations
+- [ ] File uploads validated (type, size, content)
+
+### Cryptography
+- [ ] TLS 1.2+ enforced everywhere
+- [ ] Strong algorithms used (AES-256, RSA-2048+)
+- [ ] No secrets in code or version control
+- [ ] Keys stored in secrets manager
+
+### Configuration
+- [ ] Security headers configured
+- [ ] CORS restricted to allowed origins
+- [ ] Debug mode disabled in production
+- [ ] Default credentials changed
+
+### Monitoring
+- [ ] Security events logged
+- [ ] Alerts configured for suspicious activity
+- [ ] Incident response plan documented
+
+---
+
+## Related Standards
+
+- [Code Review Checklist](code-review-checklist.md) - Security review section
+- [Testing Standards](testing-standards.md) - Security testing integration
+- [Logging Standards](logging-standards.md) - Security logging
+- [Error Code Standards](error-code-standards.md) - AUTH error codes
+- [Deployment Standards](deployment-standards.md) - Pre-deployment security checklist
+
+---
+
+## Version History
+
+| Version | Date | Changes |
+|---------|------|---------|
+| 1.1.0 | 2026-01-29 | Refactored: Split into Rules + Guide, moved explanations to guide |
+| 1.0.0 | 2026-01-29 | Initial release |
+
+---
+
+## License
+
+This standard is released under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

package/bundled/core/spec-driven-development.md

@@ -1,338 +1,39 @@
 # Spec-Driven Development (SDD) Standards
 
-**Version**: 1.3.0
-**Last Updated**: 2026-01-19
+**Version**: 2.1.0
+**Last Updated**: 2026-01-26
 **Applicability**: All projects adopting Spec-Driven Development
-
-> **Language**: [English](../core/spec-driven-development.md) | [繁體中文](../locales/zh-TW/core/spec-driven-development.md)
-
----
-
-## Purpose
-
-This standard defines the principles and workflows for Spec-Driven Development (SDD), ensuring that changes are planned, documented, and approved via specifications before implementation.
-
-**Key Benefits**:
-- Reduced miscommunication between stakeholders and developers
-- Clear audit trail for all changes
-- Easier onboarding for new team members
-
----
-
-## SDD Workflow
-
-```
-┌──────────────┐    ┌──────────────┐    ┌──────────────┐
-│   Proposal   │───▶│    Review    │───▶│Implementation│
-└──────────────┘    └──────────────┘    └──────────────┘
-                                               │
-                                               ▼
-                    ┌──────────────┐    ┌──────────────┐
-                    │   Archive    │◀───│ Verification │
-                    └──────────────┘    └──────────────┘
-```
-
-### Workflow Stages
-
-| Stage | Description | Artifacts |
-|-------|-------------|-----------|
-| **Proposal** | Define what to change and why | `proposal.md` |
-| **Review** | Stakeholder approval | Review comments, approval record |
-| **Implementation** | Execute the approved spec | Code, tests, docs |
-| **Verification** | Confirm implementation matches spec | Test results, review |
-| **Archive** | Close and archive the spec | Archived spec with links to commits/PRs |
-
----
-
-## Core Principles
-
-### 1. Priority of SDD Tool Commands
-
-**Rule**: When an SDD tool (such as OpenSpec, Spec Kit, etc.) is integrated and provides specific commands (e.g., slash commands like `/openspec` or `/spec`), AI assistants MUST prioritize using these commands over manual file editing.
-
-**Rationale**:
-- **Consistency**: Tools ensure the spec structure follows strict schemas.
-- **Traceability**: Commands often handle logging, IDs, and linking automatically.
-- **Safety**: Tools may have built-in validation preventing invalid states.
-
-**Example**:
-- ✅ Use `/openspec proposal "Add Login"` instead of manually creating `changes/add-login/proposal.md`.
-
----
-
-### 2. Methodology Over Tooling
-
-**Rule**: SDD is a methodology, not bound to a single tool. While OpenSpec is a common implementation, these standards apply to any SDD tool (e.g., Spec Kit).
-
-**Guidelines**:
-- **Universal Flow**: Proposal -> Review -> Implementation -> Verification -> Archive.
-- **Tool Adaptation**: Adapt to the specific commands and patterns of the active SDD tool in the workspace.
-
----
-
-### 3. Spec First, Code Second
-
-**Rule**: No functional code changes shall be made without a corresponding approved specification or change proposal.
-
-**Exceptions**:
-- Critical hotfixes (restore service immediately, document later).
-- Trivial changes (typos, comments, formatting).
+**Scope**: universal
+**Industry Standards**: None (Emerging 2025+ methodology)
+**References**: [specmatic.io](https://specmatic.io/)
 
 ---
 
-## Spec Document Template
-
-### Proposal Template
-
-```markdown
-# [SPEC-ID] Feature Title
-
 ## Summary
-Brief description of the proposed change.
-
-## Motivation
-Why is this change needed? What problem does it solve?
-
-## Detailed Design
-Technical approach, affected components, data flow.
-
-## Acceptance Criteria
-- [ ] Criterion 1
-- [ ] Criterion 2
-
-## Dependencies
-List any dependencies on other specs or external systems.
-
-## Risks
-Potential risks and mitigation strategies.
-```
-
----
-
-## Integration with Other Standards
-
-### With Commit Message Guide
-
-When implementing an approved spec, reference the spec ID in commit messages:
-
-```
-feat(auth): implement login feature
-
-Implements SPEC-001 login functionality with OAuth2 support.
-
-Refs: SPEC-001
-```
-
-### With Check-in Standards
 
-Before checking in code for a spec:
+Spec-Driven Development (SDD) is an AI-era methodology (2025+) distinct from traditional TDD/BDD/ATDD. It ensures that changes are planned, documented, and approved via specifications before implementation. The core principle is **"Spec First, Code Second"** - no functional code changes without a corresponding approved specification.
 
-1. ✅ Spec is approved
-2. ✅ Implementation matches spec
-3. ✅ Tests cover acceptance criteria
-4. ✅ Spec ID referenced in PR
-
-### With Code Review Checklist
-
-Reviewers should verify:
-
-- [ ] Change matches approved spec
-- [ ] No scope creep beyond spec
-- [ ] Spec acceptance criteria met
-
----
-
-## Common SDD Tools
-
-| Tool | Description | Command Examples |
-|------|-------------|------------------|
-| **OpenSpec** | Specification management | `/openspec proposal`, `/openspec approve` |
-| **Spec Kit** | Lightweight spec tracking | `/spec create`, `/spec close` |
-| **Manual** | No tool, file-based | Create `specs/SPEC-XXX.md` manually |
+SDD operates at different maturity levels: Spec-first (discard after completion), Spec-anchored (maintain throughout evolution), and Spec-as-source (spec is only source, code auto-generated). The methodology uses Forward Derivation to generate test artifacts (BDD scenarios, TDD skeletons, contracts) from specifications.
 
 ---
 
-## Best Practices
-
-### Do's
-
-- ✅ Keep specs focused and atomic (one change per spec)
-- ✅ Include clear acceptance criteria
-- ✅ Link specs to implementation PRs
-- ✅ Archive specs after completion
-
-### Don'ts
-
-- ❌ Start coding before spec approval
-- ❌ Modify scope during implementation without updating spec
-- ❌ Leave specs in limbo (always close or archive)
-- ❌ Skip verification step
-
----
-
-## Integration with Reverse Engineering
-
-### Overview
-
-For existing codebases without specifications, use [Reverse Engineering Standards](reverse-engineering-standards.md) to generate SDD-compatible proposal drafts.
-
-### Reverse Engineering → SDD Pipeline
-
-```
-┌─────────────────────────────────────────────────────────────────────────┐
-│                  Reverse Engineering → SDD Pipeline                      │
-├─────────────────────────────────────────────────────────────────────────┤
-│                                                                         │
-│   Existing Code                                                         │
-│        │                                                                │
-│        ▼                                                                │
-│   ┌────────────────────────────────────────────────────────────┐       │
-│   │ /reverse-spec                                               │       │
-│   │   • Code scanning → Technical inventory [Confirmed]         │       │
-│   │   • Test analysis → Acceptance criteria [Confirmed/Inferred]│       │
-│   │   • Gap identification → [Unknown] items                    │       │
-│   └────────────────────────────────────────────────────────────┘       │
-│        │                                                                │
-│        ▼                                                                │
-│   DRAFT SPEC (Reverse-Engineered)                                       │
-│        │                                                                │
-│        ▼                                                                │
-│   ┌────────────────────────────────────────────────────────────┐       │
-│   │ SDD Review Process                                          │       │
-│   │   • Human fills [Unknown] sections (motivation, risks)      │       │
-│   │   • Stakeholder validation of [Inferred] items              │       │
-│   │   • Formal approval                                         │       │
-│   └────────────────────────────────────────────────────────────┘       │
-│        │                                                                │
-│        ▼                                                                │
-│   APPROVED SPEC → Normal SDD workflow continues                         │
-│                                                                         │
-└─────────────────────────────────────────────────────────────────────────┘
-```
-
-### Requirements for Reverse-Engineered Specs
-
-When a specification is generated via reverse engineering:
-
-1. **Mark Status**: Include `Status: Draft (Reverse-Engineered)` in metadata
-2. **Fill Unknowns**: All `[Unknown]` sections MUST be filled by humans before approval
-3. **Validate Inferences**: All `[Inferred]` items must be reviewed and confirmed
-4. **Standard Review**: Follow normal SDD review process before implementation
-5. **Source Citations**: Maintain file:line references for traceability
-
-### When to Use Reverse Engineering
-
-| Scenario | Approach |
-|----------|----------|
-| Legacy system modernization | Start with reverse engineering |
-| Documenting undocumented code | Generate specs from code |
-| New team onboarding | Extract specifications for knowledge transfer |
-| Pre-refactoring documentation | Create specs before major changes |
-
-### Related Commands
-
-| Command | Purpose |
-|---------|---------|
-| `/reverse-spec` | Generate SDD specification from existing code |
-| `/reverse-bdd` | Convert acceptance criteria to Gherkin scenarios |
-| `/reverse-tdd` | Analyze test coverage against BDD scenarios |
+**Full Guide: [SDD Guide](../methodologies/guides/sdd-guide.md)**
 
 ---
 
-## Integration with Forward Derivation
-
-### Overview
-
-After a specification is approved, use [Forward Derivation Standards](forward-derivation-standards.md) to automatically generate BDD scenarios, TDD test skeletons, and ATDD acceptance tests from the Acceptance Criteria.
-
-### Forward Derivation → SDD Pipeline
-
-```
-┌─────────────────────────────────────────────────────────────────────────┐
-│                  Approved Spec → Forward Derivation Pipeline             │
-├─────────────────────────────────────────────────────────────────────────┤
-│                                                                         │
-│   APPROVED SPEC-XXX.md                                                  │
-│        │                                                                │
-│        ▼                                                                │
-│   ┌────────────────────────────────────────────────────────────┐       │
-│   │ /derive-all specs/SPEC-XXX.md                               │       │
-│   │   • Parse Acceptance Criteria                               │       │
-│   │   • Transform AC → Gherkin scenarios [Generated]           │       │
-│   │   • Generate TDD test skeletons [Generated]                │       │
-│   │   • Create ATDD acceptance tables [Generated]              │       │
-│   └────────────────────────────────────────────────────────────┘       │
-│        │                                                                │
-│        ▼                                                                │
-│   OUTPUT FILES                                                          │
-│   ├── features/SPEC-XXX.feature (BDD)                                  │
-│   ├── tests/SPEC-XXX.test.ts (TDD)                                     │
-│   └── acceptance/SPEC-XXX-acceptance.md (ATDD)                         │
-│        │                                                                │
-│        ▼                                                                │
-│   HUMAN REVIEW → BDD/TDD workflow continues                            │
-│                                                                         │
-└─────────────────────────────────────────────────────────────────────────┘
-```
+## Quick Reference
 
-### When to Use Forward Derivation
-
-| Scenario | Approach |
-|----------|----------|
-| Spec approved, starting implementation | Use `/derive-all` to generate test structures |
-| Need BDD scenarios quickly | Use `/derive-bdd` for Gherkin generation |
-| Starting TDD workflow | Use `/derive-tdd` for test skeletons |
-| Manual acceptance testing | Use `/derive-atdd` for test tables |
-
-### Related Commands
-
-| Command | Input | Output | Purpose |
-|---------|-------|--------|---------|
-| `/derive-bdd` | SPEC-XXX.md | .feature | AC → Gherkin scenarios |
-| `/derive-tdd` | SPEC-XXX.md | .test.ts | AC → Test skeletons |
-| `/derive-atdd` | SPEC-XXX.md | acceptance.md | AC → Test tables |
-| `/derive-all` | SPEC-XXX.md | All above | Full derivation pipeline |
-
----
+| Aspect | Description |
+|--------|-------------|
+| **Core Workflow** | Proposal → Review → Implementation → Verification → Archive |
+| **Key Principle** | Spec First, Code Second |
+| **Test Generation** | Forward Derivation (/derive-bdd, /derive-tdd, /derive-all) |
+| **Maturity Levels** | Spec-first, Spec-anchored, Spec-as-source |
+| **Tools** | OpenSpec, Spec Kit, Manual (file-based) |
 
 ## Related Standards
 
-- [Forward Derivation Standards](forward-derivation-standards.md) - Specification-to-test transformation (Spec → BDD/TDD/ATDD)
-- [Reverse Engineering Standards](reverse-engineering-standards.md) - Code-to-specification transformation (Code → Spec)
-- [Test-Driven Development](test-driven-development.md) - TDD workflow and SDD integration
-- [Behavior-Driven Development](behavior-driven-development.md) - BDD workflow with Given-When-Then scenarios
-- [Acceptance Test-Driven Development](acceptance-test-driven-development.md) - ATDD workflow for business acceptance
-- [Testing Standards](testing-standards.md) - Testing framework and best practices (or use `/testing-guide` skill)
-- [Test Completeness Dimensions](test-completeness-dimensions.md) - 7-dimension test coverage
-- [Commit Message Guide](commit-message-guide.md) - Commit message conventions
-- [Code Check-in Standards](checkin-standards.md) - Code check-in requirements
-- [Code Review Checklist](code-review-checklist.md) - Code review guidelines
-- [Documentation Structure](documentation-structure.md) - Documentation structure standards
-
----
-
-## Version History
-
-| Version | Date | Changes |
-|---------|------|---------|
-| 1.4.0 | 2026-01-19 | Added: Integration with Forward Derivation section, derive commands |
-| 1.3.0 | 2026-01-19 | Added: Integration with Reverse Engineering section, related commands |
-| 1.2.0 | 2026-01-05 | Added: IEEE 830-1998 and SWEBOK v4.0 Chapter 1 (Software Requirements) to References |
-| 1.1.0 | 2025-12-24 | Added: Workflow diagram, Spec template, Integration guide, Best practices, Related standards, License |
-| 1.0.0 | 2025-12-23 | Initial SDD standard definition |
-
----
-
-## References
-
-- [OpenSpec Documentation](https://github.com/openspec)
-- [Design Documents Best Practices](https://www.industrialempathy.com/posts/design-docs-at-google/)
-- [ADR (Architecture Decision Records)](https://adr.github.io/)
-- [IEEE 830-1998 - Software Requirements Specifications](https://standards.ieee.org/ieee/830/1222/) - Requirements documentation standard
-- [SWEBOK v4.0 - Chapter 1: Software Requirements](https://www.computer.org/education/bodies-of-knowledge/software-engineering) - IEEE Computer Society
-
----
-
-## License
-
-This standard is released under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).
+- [Forward Derivation Standards](forward-derivation-standards.md)
+- [Reverse Engineering Standards](reverse-engineering-standards.md)
+- [Test-Driven Development](test-driven-development.md)
+- [Behavior-Driven Development](behavior-driven-development.md)