codex-genesis-harness 0.1.4 → 0.1.6

package/.codex/skills/genesis-harness/checklists/requirements-validation.md

@@ -1,211 +1,211 @@
-# Requirements Validation Checklist
-
-**Purpose**: Validate that all requirements are clear, complete, and aligned before implementation starts.
-
-**Status**: MANDATORY - Use after Q&A, before creating contracts and tests.
-
-## Completeness Check
-
-- [ ] **All Q&A items answered**:
-  - No "TBD" fields remaining?
-  - No "Unknown" fields that can be resolved?
-  - All dependencies documented?
-
-- [ ] **Requirements are Specific**:
-  - "User can upload file" → ✅ "User can upload JPEG/PNG < 5MB to profile"
-  - Vague requirements identified and clarified?
-  - Units and formats specified (MB, seconds, JSON)?
-
-- [ ] **Requirements are Measurable**:
-  - Success can be verified objectively?
-  - Metrics and thresholds defined?
-  - Acceptance criteria quantified where possible?
-
-- [ ] **Requirements are Achievable**:
-  - Technical team believes it's feasible?
-  - Skills and knowledge present?
-  - Resource constraints acknowledged?
-  - Timeline realistic?
-
-- [ ] **Requirements are Relevant**:
-  - Aligned with product roadmap?
-  - Business value clear?
-  - Won't be made obsolete by other work?
-
-## Scope Validation
-
-- [ ] **Scope is bounded**:
-  - Clear IN/OUT distinction?
-  - Related features NOT in scope documented?
-  - Phase 2/future work identified?
-
-- [ ] **No scope creep identified**:
-  - Requirements are focused?
-  - "Nice to have" separated from "must have"?
-  - Dependencies on other features noted?
-
-- [ ] **Edge cases included in scope**:
-  - Error cases considered?
-  - Boundary conditions documented?
-  - Performance edge cases noted?
-
-## Technical Feasibility
-
-- [ ] **Technical approach approved**:
-  - Architect reviewed proposed solution?
-  - Major technical decisions documented?
-  - No unknowns that are blockers?
-
-- [ ] **API/Contract defined**:
-  - Input schema clear?
-  - Output schema clear?
-  - Error responses defined?
-  - Breaking changes identified?
-
-- [ ] **Data Model defined**:
-  - Database schema changes clear?
-  - Backward compatibility strategy defined?
-  - Data migration plan if needed?
-
-- [ ] **Dependencies external/internal identified**:
-  - External APIs or services needed?
-  - Libraries or tools required?
-  - Existing modules to integrate with?
-  - Build/deployment requirements?
-
-## Acceptance Criteria Validation
-
-- [ ] **Acceptance Criteria are testable**:
-  - Each criterion can be verified?
-  - Test cases can be written?
-  - No subjective criteria ("looks good")?
-
-- [ ] **Acceptance Criteria are complete**:
-  - Happy path covered?
-  - Error paths included?
-  - Edge cases represented?
-  - Performance criteria included?
-
-- [ ] **Acceptance Criteria are prioritized**:
-  - Must-have criteria clear?
-  - Nice-to-have criteria separate?
-  - Dependencies between criteria noted?
-
-## Stakeholder Alignment
-
-- [ ] **Product owner approved**:
-  - Requirements match product vision?
-  - Business value documented?
-  - Conflicts with other priorities resolved?
-
-- [ ] **Tech lead/architect approved**:
-  - Technical feasibility confirmed?
-  - Approach aligns with architecture?
-  - Technical risks identified?
-
-- [ ] **No conflicting requirements**:
-  - Performance vs. complexity tradeoffs addressed?
-  - Security vs. usability resolved?
-  - Team capacity confirmed?
-
-## Documentation & Communication
-
-- [ ] **Requirements documented clearly**:
-  - User stories well-formed?
-  - Acceptance criteria listed?
-  - Related documents linked?
-
-- [ ] **Ambiguities resolved**:
-  - Team discussed unclear points?
-  - Assumptions documented?
-  - Glossary for domain terms created?
-
-- [ ] **Team has common understanding**:
-  - Walkthrough with key people done?
-  - Q&A items captured in writing?
-  - No silent disagreements about scope?
-
-## Risk Assessment
-
-- [ ] **Technical risks identified**:
-  - Unknown technologies or patterns?
-  - Performance risks documented?
-  - Integration risks noted?
-
-- [ ] **Business risks identified**:
-  - Dependencies on external parties?
-  - Market timing risks?
-  - Competitive concerns?
-
-- [ ] **Mitigation strategies defined**:
-  - Risk reduction tactics identified?
-  - Contingency plans for critical risks?
-  - Escalation criteria defined?
-
-## Testing & Quality
-
-- [ ] **Test Strategy defined**:
-  - Unit test scope?
-  - Integration test scenarios?
-  - E2E test critical paths?
-  - Performance test requirements?
-
-- [ ] **Test Data & Fixtures planned**:
-  - What data needed for testing?
-  - Edge case datasets created?
-  - Load test scenarios defined?
-
-- [ ] **Quality Standards aligned**:
-  - Code review criteria?
-  - Test coverage target (80%+)?
-  - Performance benchmarks?
-  - Security standards?
-
-## Sign-Off
-
-- [ ] **Product Owner**: _Name_ ☐ Approved
-- [ ] **Tech Lead**: _Name_ ☐ Approved  
-- [ ] **Team Lead**: _Name_ ☐ Approved
-- [ ] **Any additional stakeholders**: ☐ Approved
-
-## Implementation Readiness
-
-### Ready to Proceed:
-- [ ] All Q&A complete
-- [ ] All validations passed
-- [ ] All stakeholders approved
-- [ ] No blockers identified
-- [ ] Team ready to start
-
-### If NOT ready:
-- [ ] List items preventing readiness
-- [ ] Owner assigned for each blocker
-- [ ] Timeline to resolve each blocker
-
----
-
-## Usage
-
-```
-After completing feature/bug/refactor Q&A:
-
-1. Run through this validation checklist
-2. Address any gaps or concerns
-3. Get sign-offs from stakeholders
-4. Only then proceed to:
-   - Contract definition
-   - Test creation
-   - Implementation planning
-```
-
-## Validation Result
-
-**Status**: ☐ Ready / ☐ Needs Work
-
-**Blockers** (if any):
-- _item_
-- _item_
-
-**Owner**: _Name_  
-**Date**: _YYYY-MM-DD_  
-**Next Steps**: _Action items_
+# Requirements Validation Checklist
+
+**Purpose**: Validate that all requirements are clear, complete, and aligned before implementation starts.
+
+**Status**: MANDATORY - Use after Q&A, before creating contracts and tests.
+
+## Completeness Check
+
+- [ ] **All Q&A items answered**:
+  - No "TBD" fields remaining?
+  - No "Unknown" fields that can be resolved?
+  - All dependencies documented?
+
+- [ ] **Requirements are Specific**:
+  - "User can upload file" → ✅ "User can upload JPEG/PNG < 5MB to profile"
+  - Vague requirements identified and clarified?
+  - Units and formats specified (MB, seconds, JSON)?
+
+- [ ] **Requirements are Measurable**:
+  - Success can be verified objectively?
+  - Metrics and thresholds defined?
+  - Acceptance criteria quantified where possible?
+
+- [ ] **Requirements are Achievable**:
+  - Technical team believes it's feasible?
+  - Skills and knowledge present?
+  - Resource constraints acknowledged?
+  - Timeline realistic?
+
+- [ ] **Requirements are Relevant**:
+  - Aligned with product roadmap?
+  - Business value clear?
+  - Won't be made obsolete by other work?
+
+## Scope Validation
+
+- [ ] **Scope is bounded**:
+  - Clear IN/OUT distinction?
+  - Related features NOT in scope documented?
+  - Phase 2/future work identified?
+
+- [ ] **No scope creep identified**:
+  - Requirements are focused?
+  - "Nice to have" separated from "must have"?
+  - Dependencies on other features noted?
+
+- [ ] **Edge cases included in scope**:
+  - Error cases considered?
+  - Boundary conditions documented?
+  - Performance edge cases noted?
+
+## Technical Feasibility
+
+- [ ] **Technical approach approved**:
+  - Architect reviewed proposed solution?
+  - Major technical decisions documented?
+  - No unknowns that are blockers?
+
+- [ ] **API/Contract defined**:
+  - Input schema clear?
+  - Output schema clear?
+  - Error responses defined?
+  - Breaking changes identified?
+
+- [ ] **Data Model defined**:
+  - Database schema changes clear?
+  - Backward compatibility strategy defined?
+  - Data migration plan if needed?
+
+- [ ] **Dependencies external/internal identified**:
+  - External APIs or services needed?
+  - Libraries or tools required?
+  - Existing modules to integrate with?
+  - Build/deployment requirements?
+
+## Acceptance Criteria Validation
+
+- [ ] **Acceptance Criteria are testable**:
+  - Each criterion can be verified?
+  - Test cases can be written?
+  - No subjective criteria ("looks good")?
+
+- [ ] **Acceptance Criteria are complete**:
+  - Happy path covered?
+  - Error paths included?
+  - Edge cases represented?
+  - Performance criteria included?
+
+- [ ] **Acceptance Criteria are prioritized**:
+  - Must-have criteria clear?
+  - Nice-to-have criteria separate?
+  - Dependencies between criteria noted?
+
+## Stakeholder Alignment
+
+- [ ] **Product owner approved**:
+  - Requirements match product vision?
+  - Business value documented?
+  - Conflicts with other priorities resolved?
+
+- [ ] **Tech lead/architect approved**:
+  - Technical feasibility confirmed?
+  - Approach aligns with architecture?
+  - Technical risks identified?
+
+- [ ] **No conflicting requirements**:
+  - Performance vs. complexity tradeoffs addressed?
+  - Security vs. usability resolved?
+  - Team capacity confirmed?
+
+## Documentation & Communication
+
+- [ ] **Requirements documented clearly**:
+  - User stories well-formed?
+  - Acceptance criteria listed?
+  - Related documents linked?
+
+- [ ] **Ambiguities resolved**:
+  - Team discussed unclear points?
+  - Assumptions documented?
+  - Glossary for domain terms created?
+
+- [ ] **Team has common understanding**:
+  - Walkthrough with key people done?
+  - Q&A items captured in writing?
+  - No silent disagreements about scope?
+
+## Risk Assessment
+
+- [ ] **Technical risks identified**:
+  - Unknown technologies or patterns?
+  - Performance risks documented?
+  - Integration risks noted?
+
+- [ ] **Business risks identified**:
+  - Dependencies on external parties?
+  - Market timing risks?
+  - Competitive concerns?
+
+- [ ] **Mitigation strategies defined**:
+  - Risk reduction tactics identified?
+  - Contingency plans for critical risks?
+  - Escalation criteria defined?
+
+## Testing & Quality
+
+- [ ] **Test Strategy defined**:
+  - Unit test scope?
+  - Integration test scenarios?
+  - E2E test critical paths?
+  - Performance test requirements?
+
+- [ ] **Test Data & Fixtures planned**:
+  - What data needed for testing?
+  - Edge case datasets created?
+  - Load test scenarios defined?
+
+- [ ] **Quality Standards aligned**:
+  - Code review criteria?
+  - Test coverage target (80%+)?
+  - Performance benchmarks?
+  - Security standards?
+
+## Sign-Off
+
+- [ ] **Product Owner**: _Name_ ☐ Approved
+- [ ] **Tech Lead**: _Name_ ☐ Approved  
+- [ ] **Team Lead**: _Name_ ☐ Approved
+- [ ] **Any additional stakeholders**: ☐ Approved
+
+## Implementation Readiness
+
+### Ready to Proceed:
+- [ ] All Q&A complete
+- [ ] All validations passed
+- [ ] All stakeholders approved
+- [ ] No blockers identified
+- [ ] Team ready to start
+
+### If NOT ready:
+- [ ] List items preventing readiness
+- [ ] Owner assigned for each blocker
+- [ ] Timeline to resolve each blocker
+
+---
+
+## Usage
+
+```
+After completing feature/bug/refactor Q&A:
+
+1. Run through this validation checklist
+2. Address any gaps or concerns
+3. Get sign-offs from stakeholders
+4. Only then proceed to:
+   - Contract definition
+   - Test creation
+   - Implementation planning
+```
+
+## Validation Result
+
+**Status**: ☐ Ready / ☐ Needs Work
+
+**Blockers** (if any):
+- _item_
+- _item_
+
+**Owner**: _Name_  
+**Date**: _YYYY-MM-DD_  
+**Next Steps**: _Action items_

package/.codex/skills/genesis-harness/references/planning-schema.md

@@ -1,35 +1,35 @@
-# Planning Schema Reference
-
-Use this file when creating or auditing `.planning/`.
-
-## Core Files
-
-- `PROJECT.md`: product identity, users, value, scope, out of scope, constraints, assumptions, milestone, success criteria.
-- `REQUIREMENTS.md`: functional requirements, non-functional requirements, user stories, acceptance criteria, edge cases, unknowns.
-- `ROADMAP.md`: milestones, phases, dependencies, status, phase acceptance criteria.
-- `STATE.md`: current phase, active feature or bug, last task, next task, blockers, latest verification.
-- `STACK.md`: language, framework, runtime, database, package manager, tests, lint/typecheck, deployment, local commands.
-- `ARCHITECTURE.md`: architecture, boundaries, data flow, dependency direction, service boundaries, principles, forbidden patterns.
-- `DESIGN.md`: UX principles, screens, components, state management, accessibility, constraints.
-- `API_DOCS.md`: endpoints, examples, errors, auth, versioning.
-- `INTEGRATIONS.md`: services, SDKs, environment variables, secrets, failure handling, fallback behavior, limits.
-- `CONVENTIONS.md`: naming, folders, style, errors, logging, testing, API, security, patterns to follow and avoid.
-- `PITFALLS.md`: common mistakes, risky areas, fragile dependencies, warnings.
-- `LESSONS_LEARNED.md`: bug lessons with root cause, failed assumption, correct pattern, prevention, changed files, verification.
-- `SPEC_CHANGELOG.md`: every spec-affecting change.
-- `QUALITY_SCORE.md`: quality rubric scores and next actions.
-
-## Required Subtrees
-
-- `diagrams/`
-- `research/`
-- `decisions/`
-- `phases/`
-- `features/`
-- `bugs/`
-- `audits/`
-- `checks/`
-- `quick/`
-- `codebase/`
-- `templates/`
-
+# Planning Schema Reference
+
+Use this file when creating or auditing `.planning/`.
+
+## Core Files
+
+- `PROJECT.md`: product identity, users, value, scope, out of scope, constraints, assumptions, milestone, success criteria.
+- `REQUIREMENTS.md`: functional requirements, non-functional requirements, user stories, acceptance criteria, edge cases, unknowns.
+- `ROADMAP.md`: milestones, phases, dependencies, status, phase acceptance criteria.
+- `STATE.md`: current phase, active feature or bug, last task, next task, blockers, latest verification.
+- `STACK.md`: language, framework, runtime, database, package manager, tests, lint/typecheck, deployment, local commands.
+- `ARCHITECTURE.md`: architecture, boundaries, data flow, dependency direction, service boundaries, principles, forbidden patterns.
+- `DESIGN.md`: UX principles, screens, components, state management, accessibility, constraints.
+- `API_DOCS.md`: endpoints, examples, errors, auth, versioning.
+- `INTEGRATIONS.md`: services, SDKs, environment variables, secrets, failure handling, fallback behavior, limits.
+- `CONVENTIONS.md`: naming, folders, style, errors, logging, testing, API, security, patterns to follow and avoid.
+- `PITFALLS.md`: common mistakes, risky areas, fragile dependencies, warnings.
+- `LESSONS_LEARNED.md`: bug lessons with root cause, failed assumption, correct pattern, prevention, changed files, verification.
+- `SPEC_CHANGELOG.md`: every spec-affecting change.
+- `QUALITY_SCORE.md`: quality rubric scores and next actions.
+
+## Required Subtrees
+
+- `diagrams/`
+- `research/`
+- `decisions/`
+- `phases/`
+- `features/`
+- `bugs/`
+- `audits/`
+- `checks/`
+- `quick/`
+- `codebase/`
+- `templates/`
+

package/.codex/skills/genesis-harness/references/quality-rubric.md

@@ -1,21 +1,21 @@
-# Quality Rubric
-
-Use this file when updating `.planning/QUALITY_SCORE.md`.
-
-| Score | Meaning |
-|---:|---|
-| 0 | Unknown, absent, or not evaluated |
-| 2 | Known major gaps with no mitigation |
-| 4 | Basic structure exists but is inconsistent or mostly manual |
-| 6 | Working baseline with known gaps and follow-up tasks |
-| 8 | Strong, verified, documented, and mostly automated |
-| 10 | Mature, automated, documented, reviewed, and low-risk |
-
-## Areas
-
-- Architecture: module boundaries, dependency direction, diagrams, ADRs, forbidden patterns.
-- Tests: regression coverage, smoke tests, edge cases, failing-first evidence, repeatability.
-- Docs Sync: behavior docs, changelog entries, impact matrix compliance.
-- Security: auth, secrets, data protection, dependency risk, destructive-operation safeguards.
-- Maintainability: naming, duplication, dead code, conventions, module size, refactor risk.
-- Observability: logs, metrics, traces, errors, health checks, debug commands, inspection workflow.
+# Quality Rubric
+
+Use this file when updating `.planning/QUALITY_SCORE.md`.
+
+| Score | Meaning |
+|---:|---|
+| 0 | Unknown, absent, or not evaluated |
+| 2 | Known major gaps with no mitigation |
+| 4 | Basic structure exists but is inconsistent or mostly manual |
+| 6 | Working baseline with known gaps and follow-up tasks |
+| 8 | Strong, verified, documented, and mostly automated |
+| 10 | Mature, automated, documented, reviewed, and low-risk |
+
+## Areas
+
+- Architecture: module boundaries, dependency direction, diagrams, ADRs, forbidden patterns.
+- Tests: regression coverage, smoke tests, edge cases, failing-first evidence, repeatability.
+- Docs Sync: behavior docs, changelog entries, impact matrix compliance.
+- Security: auth, secrets, data protection, dependency risk, destructive-operation safeguards.
+- Maintainability: naming, duplication, dead code, conventions, module size, refactor risk.
+- Observability: logs, metrics, traces, errors, health checks, debug commands, inspection workflow.

package/.codex/skills/genesis-harness/references/research-rubric.md

@@ -1,41 +1,41 @@
-# Research Rubric
-
-Use this file before planning or implementing non-trivial work.
-
-## Required Evidence
-
-| Evidence | Required? | Notes |
-|---|---:|---|
-| Local code paths | Yes | Include file paths or commands. |
-| Similar existing patterns | Yes | Prefer repo conventions over new abstractions. |
-| Official docs | When available | Cite URL or doc name and date checked. |
-| Reputable external examples | When useful | Do not copy architecture blindly. |
-| Unknowns | Yes | Record gaps instead of inventing facts. |
-
-## Output Format
-
-```md
-## Research: <topic>
-
-Date:
-Question:
-
-## Local Evidence
-
-| File / Command | Finding | Impact |
-|---|---|---|
-
-## External Evidence
-
-| Source | Date Checked | Finding | Impact |
-|---|---|---|---|
-
-## Decision Impact
-
-- [ ] TBD
-
-## Confidence / Gaps
-
-- [ ] TBD
-```
-
+# Research Rubric
+
+Use this file before planning or implementing non-trivial work.
+
+## Required Evidence
+
+| Evidence | Required? | Notes |
+|---|---:|---|
+| Local code paths | Yes | Include file paths or commands. |
+| Similar existing patterns | Yes | Prefer repo conventions over new abstractions. |
+| Official docs | When available | Cite URL or doc name and date checked. |
+| Reputable external examples | When useful | Do not copy architecture blindly. |
+| Unknowns | Yes | Record gaps instead of inventing facts. |
+
+## Output Format
+
+```md
+## Research: <topic>
+
+Date:
+Question:
+
+## Local Evidence
+
+| File / Command | Finding | Impact |
+|---|---|---|
+
+## External Evidence
+
+| Source | Date Checked | Finding | Impact |
+|---|---|---|---|
+
+## Decision Impact
+
+- [ ] TBD
+
+## Confidence / Gaps
+
+- [ ] TBD
+```
+