@williambeto/ai-workflow 1.19.1 → 2.2.0

package/templates/SPEC.template.md

@@ -1,397 +0,0 @@
-# Functional Specification
-
-## Objective
-
-[What outcome this spec must achieve]
-
-## Context
-
-[Relevant product/business/technical context needed to understand this spec]
-
-## Problem
-
-[Current pain, failure mode, or gap this work must solve]
-
-## Title
-
-[Short, clear title for the specification]
-
-## Status
-
-Draft | Ready for technical plan | Needs clarification | Too broad | Not recommended
-
-## Summary
-
-[Short explanation of what this specification covers]
-
-## Source requirement
-
-[Reference the approved requirement used as input]
-
-Example:
-
-```txt
-requirements/feature-name.md
-```
-
-## Actors
-
-- [Actor 1]
-- [Actor 2]
-
-Examples:
-
-- unauthenticated user;
-- authenticated user;
-- admin user;
-- system;
-- external service;
-- maintainer.
-
-## Scope
-
-### Included
-
-- [Item included in this specification]
-- [Item included in this specification]
-
-### Not included
-
-- [Item explicitly out of scope]
-- [Item explicitly out of scope]
-
-## Functional requirements
-
-- [Functional requirement 1]
-- [Functional requirement 2]
-
-Use `Not applicable` only if this spec has no user/system behavior changes.
-
-## Non-functional requirements
-
-### Accessibility
-
-[Requirement or `Not applicable`]
-
-### Performance
-
-[Requirement or `Not applicable`]
-
-### Security
-
-[Requirement or `Not applicable`]
-
-### Compatibility
-
-[Requirement or `Not applicable`]
-
-### Reliability
-
-[Requirement or `Not applicable`]
-
-## Technical constraints
-
-- [Constraint 1]
-- [Constraint 2]
-
-Include framework, runtime, infra, policy, migration, or rollout constraints.
-
-## Current behavior
-
-[Describe how the system currently behaves]
-
-Use `Not applicable` if this is a new feature or new project.
-
-## Desired behavior
-
-[Describe the expected behavior after this specification is implemented]
-
-## Main flow
-
-1. [Step 1]
-2. [Step 2]
-3. [Step 3]
-
-## Alternative flows
-
-### Flow 1 — [Flow name]
-
-1. [Step 1]
-2. [Step 2]
-3. [Step 3]
-
-### Flow 2 — [Flow name]
-
-1. [Step 1]
-2. [Step 2]
-3. [Step 3]
-
-Use `Not applicable` if there are no relevant alternative flows.
-
-## System states
-
-### Initial
-
-[Expected initial state]
-
-### Loading
-
-[Expected loading state]
-
-### Empty
-
-[Expected empty state]
-
-### Success
-
-[Expected success state]
-
-### Error
-
-[Expected error state]
-
-### Unauthorized
-
-[Expected behavior when the user is not authenticated]
-
-### Forbidden
-
-[Expected behavior when the user is authenticated but does not have permission]
-
-### Not found
-
-[Expected behavior when the requested resource does not exist]
-
-Use `Not applicable` for states that do not apply.
-
-## Business rules
-
-- [Business rule 1]
-- [Business rule 2]
-
-Use `Not applicable` if there are no known business rules.
-
-## Validation rules
-
-- [Validation rule 1]
-- [Validation rule 2]
-
-Use `Not applicable` if there are no validation rules.
-
-## Permissions and access
-
-- [Access rule 1]
-- [Access rule 2]
-
-Use `Not applicable` if access control is not relevant.
-
-## Data requirements
-
-- [Required data item 1]
-- [Required data item 2]
-- [Optional data item 1]
-
-Use `Not applicable` if no data requirements are relevant.
-
-## API behavior
-
-### Successful response
-
-[Expected behavior when the API succeeds]
-
-### Validation error
-
-[Expected behavior when the API returns validation errors]
-
-### Unauthorized response
-
-[Expected behavior when the API returns unauthorized]
-
-### Forbidden response
-
-[Expected behavior when the API returns forbidden]
-
-### Not found response
-
-[Expected behavior when the API returns not found]
-
-### Server error
-
-[Expected behavior when the API returns server error]
-
-### Timeout or unavailable service
-
-[Expected behavior when the API times out or is unavailable]
-
-Use `Not applicable` if the feature does not depend on an API.
-
-## UI behavior
-
-### Layout
-
-[Expected layout behavior]
-
-### Interaction
-
-[Expected user interaction behavior]
-
-### Feedback
-
-[Expected visual or textual feedback]
-
-### Responsive behavior
-
-[Expected behavior across relevant viewport sizes]
-
-### Accessibility behavior
-
-[Expected keyboard, focus, labels, semantics, and screen-reader behavior when relevant]
-
-Use `Not applicable` if the feature has no UI.
-
-## Edge cases
-
-- [Edge case 1]
-- [Edge case 2]
-- [Edge case 3]
-
-Use `None known` only when there are no relevant edge cases.
-
-## UI states
-
-### Loading
-
-[Expected behavior]
-
-### Empty
-
-[Expected behavior]
-
-### Success
-
-[Expected behavior]
-
-### Error
-
-[Expected behavior]
-
-### Unauthorized / Forbidden / Not found
-
-[Expected behavior or `Not applicable`]
-
-Use `Not applicable` if this spec has no UI.
-
-## Non-functional expectations
-
-### Accessibility
-
-[Accessibility expectation or `Not applicable`]
-
-### Performance
-
-[Performance expectation or `Not applicable`]
-
-### Security
-
-[Security expectation or `Not applicable`]
-
-### Compatibility
-
-[Browser, runtime, device, framework, or platform compatibility expectation]
-
-### Localization
-
-[Language, timezone, formatting, or translation expectation]
-
-## Acceptance criteria
-
-### Scenario 1 — [Scenario name]
-
-Given [context],  
-when [action],  
-then [expected result].
-
-### Scenario 2 — [Scenario name]
-
-Given [context],  
-when [action],  
-then [expected result].
-
-### Scenario 3 — [Scenario name]
-
-Given [context],  
-when [action],  
-then [expected result].
-
-## Assumptions
-
-- [Assumption 1]
-- [Assumption 2]
-
-Assumptions must not be treated as confirmed facts.
-
-## Open questions
-
-- [Question 1]
-- [Question 2]
-
-Use `None` only when there are no relevant open questions.
-
-## Risks
-
-| Risk     | Severity            | Impact   | Mitigation   |
-| -------- | ------------------- | -------- | ------------ |
-| [Risk 1] | High / Medium / Low | [Impact] | [Mitigation] |
-| [Risk 2] | High / Medium / Low | [Impact] | [Mitigation] |
-
-## Implementation plan
-
-1. [Step 1]
-2. [Step 2]
-3. [Step 3]
-
-Keep implementation steps high-level and reversible.
-
-## PR breakdown
-
-### PR 1 — [Title]
-
-- Objective:
-- Scope:
-- Out of scope:
-- Validation:
-
-### PR 2 — [Title]
-
-- Objective:
-- Scope:
-- Out of scope:
-- Validation:
-
-Use `Not applicable` when one PR is sufficient.
-
-## Validation plan
-
-- [Command/check 1]
-- [Command/check 2]
-- [Manual check]
-
-## Expected evidence
-
-- [Command output and result]
-- [Files changed]
-- [Acceptance criteria coverage]
-- [Untested areas or risks]
-
-## Out of scope
-
-- [Explicitly excluded item]
-- [Explicitly excluded item]
-
-## Notes
-
-[Any useful context, screenshots, examples, links, previous decisions, or related references]
-
-## Final recommendation
-
-Ready for technical plan | Needs clarification | Too broad | Not recommended

package/templates/TECH-PLAN.template.md

@@ -1,244 +0,0 @@
-# Technical Plan
-
-## Title
-
-[Short, clear title for the technical plan]
-
-## Status
-
-Draft | Ready for PR breakdown | Needs clarification | Split first | Not recommended
-
-## Summary
-
-[Short explanation of the proposed technical direction]
-
-## Source inputs
-
-### Requirement
-
-[Reference the approved requirement]
-
-Example:
-
-```txt
-requirements/feature-name.md
-```
-
-### Functional specification
-
-[Reference the approved functional specification]
-
-Example:
-
-```txt
-specs/feature-name.md
-```
-
-### Relevant constraints
-
-- [Constraint 1]
-- [Constraint 2]
-
-## Current state
-
-[Briefly describe the current implementation, project structure, relevant modules, or existing behavior]
-
-## Existing patterns to follow
-
-- [Pattern 1]
-- [Pattern 2]
-
-Examples:
-
-- existing folder structure;
-- existing component pattern;
-- existing service/repository pattern;
-- existing middleware pattern;
-- existing API client pattern;
-- existing validation pattern;
-- existing test pattern.
-
-## Proposed approach
-
-[Explain the implementation strategy]
-
-Keep this section focused on the approach, not full implementation code.
-
-## Scope
-
-### Included
-
-- [Item included in this technical plan]
-- [Item included in this technical plan]
-
-### Not included
-
-- [Item explicitly out of scope]
-- [Item explicitly out of scope]
-
-## Files likely to change
-
-- `path/to/file` — [expected change]
-- `path/to/file` — [expected change]
-
-## Files that should not change
-
-- `path/to/file` — [reason]
-- `path/to/file` — [reason]
-
-Use `Not applicable` if there are no specific files that must be protected.
-
-## Data flow / control flow
-
-1. [Step 1]
-2. [Step 2]
-3. [Step 3]
-
-Use `Not applicable` if no flow needs to be documented.
-
-## API / contract impact
-
-- [API, public interface, event, DTO, schema, route, component props, or output contract affected]
-
-Use `None expected` if there is no contract impact.
-
-## State and data considerations
-
-- [State, persistence, cache, pagination, search, filtering, sorting, nullability, default values, or data mapping consideration]
-
-Use `Not applicable` if no state or data consideration is relevant.
-
-## Security considerations
-
-- [Authentication, authorization, secrets, input validation, data exposure, or unsafe operation consideration]
-
-Use `Not applicable` if no security consideration is relevant.
-
-## Accessibility considerations
-
-- [Keyboard, focus, labels, semantic HTML, ARIA, contrast, or assistive technology consideration]
-
-Use `Not applicable` if no UI/accessibility consideration is relevant.
-
-## Performance considerations
-
-- [Rendering, network, caching, query, loop, bundle size, or build performance consideration]
-
-Use `Not applicable` if no performance consideration is relevant.
-
-## Risks and trade-offs
-
-| Risk / Trade-off | Severity            | Impact   | Mitigation   |
-| ---------------- | ------------------- | -------- | ------------ |
-| [Risk 1]         | High / Medium / Low | [Impact] | [Mitigation] |
-| [Risk 2]         | High / Medium / Low | [Impact] | [Mitigation] |
-
-## Pull request breakdown
-
-### PR 1 — [Title]
-
-#### Objective
-
-[One sentence describing the goal]
-
-#### Scope
-
-- [Item 1]
-- [Item 2]
-
-#### Expected files
-
-- `path/to/file`
-- `path/to/file`
-
-#### Validation
-
-- `command`
-- [Manual check]
-
-#### Risk
-
-- [Risk 1]
-
-### PR 2 — [Title]
-
-#### Objective
-
-[One sentence describing the goal]
-
-#### Scope
-
-- [Item 1]
-- [Item 2]
-
-#### Expected files
-
-- `path/to/file`
-- `path/to/file`
-
-#### Validation
-
-- `command`
-- [Manual check]
-
-#### Risk
-
-- [Risk 1]
-
-Use only the number of PRs needed. Do not create artificial PRs.
-
-## Validation strategy
-
-### Automated checks
-
-- `command`
-- `command`
-
-Examples:
-
-```bash
-npm run lint
-npm run typecheck
-npm test
-npm run build
-```
-
-Use project-specific commands when available.
-
-### Manual checks
-
-- [Manual check 1]
-- [Manual check 2]
-
-### Not covered
-
-- [Area not covered] — [reason]
-
-Use `None known` if all relevant areas are covered.
-
-## Assumptions
-
-- [Assumption 1]
-- [Assumption 2]
-
-Assumptions must not be treated as confirmed facts.
-
-## Open technical questions
-
-- [Question 1]
-- [Question 2]
-
-Use `None` only when there are no relevant open technical questions.
-
-## Out of scope
-
-- [Explicitly excluded item]
-- [Explicitly excluded item]
-
-## Notes
-
-[Any useful context, diagrams, references, links, previous decisions, or implementation warnings]
-
-## Final recommendation
-
-Proceed | Needs clarification | Split first | Not recommended

package/templates/change-proposal.template.md

@@ -1,97 +0,0 @@
-# Change Proposal (Lightweight Spec)
-
-Suggested save path (consumer project):
-
-`docs/specs/<spec-type>/<yyyy-mm-dd>-<change-slug>/00-proposal.md`
-
-## Spec level
-
-`tiny` | `standard` | `deep`
-
-## Spec status
-
-`Draft` | `In review` | `Ready for implementation handoff` | `Needs clarification` | `Too broad` | `Blocked`
-
-## Title
-
-[Short change title]
-
-## Objective
-
-[Outcome this change must achieve]
-
-## Background
-
-[Context needed to understand this request]
-
-## Problem
-
-[Current pain, failure mode, or gap]
-
-## Proposed change
-
-[What will change and why this is the smallest safe approach]
-
-## Scope
-
-### Included
-
-- [In-scope item]
-
-### Out of scope
-
-- [Explicitly excluded item]
-
-## Requirements
-
-- [Clear, testable requirement]
-
-## Scenarios
-
-### Scenario 1 — [Name]
-
-- Given [state]
-- When [action]
-- Then [expected result]
-
-### Scenario 2 — [Name or `Not applicable`]
-
-- Given [state]
-- When [action]
-- Then [expected result]
-
-## Technical design
-
-- [High-level design choice]
-- [Constraints, integration points, and trade-offs]
-
-## Task breakdown
-
-1. [Small implementation task]
-2. [Small implementation task]
-3. [Small validation or hardening task]
-
-## Validation plan
-
-- [Command or check]
-- [Acceptance criteria coverage method]
-
-## Risks
-
-- [Risk + mitigation]
-
-## Open questions
-
-- [Question that blocks or may affect scope]
-
-## Expected evidence
-
-- Commands executed and results
-- Files changed
-- Acceptance criteria/scenario coverage
-- Untested areas and residual risks
-
-## Handoff
-
-- Recommended next owner: `implementer` | `planner`
-- Readiness: `Ready for implementation handoff` | `Needs clarification` | `Too broad` | `Blocked`