aiwf 0.1.0

package/claude-code/simone/.simone/05_ARCHITECTURAL_DECISIONS/ADR001_Chosen_Database_System.md

@@ -0,0 +1,113 @@
+# ADR 001: Chosen Database System (EXAMPLE)
+
+## Status
+
+Accepted
+
+## Date
+
+2023-07-05
+
+## Context
+
+The backend system needs a database to store user accounts, projects, tasks, and other application data. The choice of database system will impact performance, scalability, development speed, and maintenance requirements.
+
+**Note: This is an example Architecture Decision Record to demonstrate how ADRs might be structured in the Simone framework.**
+
+We evaluated several options including:
+- Relational databases (PostgreSQL, MySQL)
+- Document databases (MongoDB, CouchDB)
+- Key-value stores (Redis, DynamoDB)
+
+## Decision
+
+We will use **MongoDB** as the primary database for this project.
+
+## Rationale
+
+The decision was based on the following factors:
+
+1. **Schema Flexibility**: The project requirements are expected to evolve rapidly during development. MongoDB's flexible schema allows us to iterate quickly without needing migrations for every model change.
+
+2. **JSON-Native Data Model**: Our API communicates in JSON, and MongoDB's BSON format aligns well with our data structures. This reduces the object-relational impedance mismatch.
+
+3. **Scalability**: MongoDB's horizontal scaling capabilities via sharding will support our growth projections.
+
+4. **Developer Productivity**: The team has prior experience with MongoDB and Mongoose ODM, which will accelerate development.
+
+5. **Performance**: For our read-heavy workloads with relatively simple query patterns, MongoDB offers good performance characteristics.
+
+6. **Ecosystem**: The robust Node.js ecosystem around MongoDB with libraries like Mongoose provides tools for validation, middleware, and other features that align with our development approach.
+
+Some concerns were raised about:
+- Lack of ACID transactions across multiple documents (though MongoDB does support multi-document transactions now)
+- Potential for data duplication in document model
+
+We determined these concerns were manageable for our use case and outweighed by the benefits.
+
+## Alternatives Considered
+
+### PostgreSQL
+
+Pros:
+- Mature, proven technology with strong ACID compliance
+- Excellent for complex relational data and joins
+- Support for JSON data types provides some schema flexibility
+
+Cons:
+- Schema migrations could slow development velocity
+- Object-relational mapping adds complexity
+- Less natural fit for our document-oriented data model
+
+### DynamoDB
+
+Pros:
+- Fully managed service with automatic scaling
+- Predictable performance with guaranteed low-latency
+- Strong consistency options
+
+Cons:
+- Less flexible query capabilities
+- AWS lock-in
+- Potentially higher cost for our access patterns
+- Less familiar to the development team
+
+## Consequences
+
+### Positive
+
+- Faster initial development due to schema flexibility
+- Easier object mapping between API and database
+- Good performance for our expected read-heavy workloads
+- Simplified deployment with MongoDB Atlas
+
+### Negative
+
+- Will require care when modeling relationships between data
+- May need supplementary systems (like Redis) for certain use cases
+- Need to handle eventual consistency in some parts of the application
+
+### Neutral
+
+- Team will need to follow MongoDB best practices for schema design
+- We'll use Mongoose ODM to provide schema validation and middleware
+
+## Implementation Notes
+
+- We will use MongoDB Atlas as the managed service for all environments
+- Mongoose will be our ODM of choice
+- Initial indexes will be created for user email, project names, and task status
+- We will implement soft deletion for most entities
+- Data validation will happen at both the Mongoose schema level and API input level
+
+## Related Decisions
+
+- ADR002: API Authentication Method
+- ADR004: Caching Strategy (pending)
+
+## References
+
+- [MongoDB Documentation](https://docs.mongodb.com/)
+- [Mongoose Documentation](https://mongoosejs.com/docs/)
+- MongoDB vs PostgreSQL comparison analysis (internal document)
+- Performance benchmark results (internal document)

package/claude-code/simone/.simone/05_ARCHITECTURAL_DECISIONS/ADR002_API_Authentication_Method.md

@@ -0,0 +1,118 @@
+# ADR 002: API Authentication Method (EXAMPLE)
+
+## Status
+
+Accepted
+
+## Date
+
+2023-07-08
+
+## Context
+
+Our API requires a secure authentication mechanism to identify users, protect resources, and control access to endpoints. We needed to select an approach that balances security, usability, and compatibility with our chosen tech stack.
+
+**Note: This is an example Architecture Decision Record to demonstrate how ADRs might be structured in the Simone framework.**
+
+Several authentication strategies were considered:
+- Session-based authentication with cookies
+- JWT (JSON Web Tokens)
+- OAuth 2.0
+- API keys
+- Combinations of the above
+
+## Decision
+
+We will use **JWT (JSON Web Tokens)** as our primary authentication method, with OAuth 2.0 support for social logins.
+
+## Rationale
+
+Our decision was based on the following factors:
+
+1. **Statelessness**: JWTs are self-contained and don't require server-side session storage, aligning well with our API-first, potentially distributed architecture.
+
+2. **Performance**: Token validation can happen without database lookups for each request, improving API response times.
+
+3. **Cross-domain compatibility**: JWTs work well across different domains and in mobile applications, supporting our multi-client strategy.
+
+4. **Security feature support**: JWTs support expiration, audience validation, and can be cryptographically signed to ensure integrity.
+
+5. **OAuth Integration**: For social logins (Google, GitHub), we can still issue JWTs after OAuth authentication, maintaining a consistent authorization approach.
+
+6. **Client-side storage**: JWTs can be securely stored in client-side mechanisms like localStorage or HTTP-only cookies, giving us flexibility in implementation.
+
+7. **Industry standard**: JWT is widely adopted, well-documented, and has strong library support in our tech stack.
+
+We acknowledged some concerns with JWT:
+- Token revocation requires additional mechanisms (blacklisting or short expiration with refresh tokens)
+- Token size can be larger than simple session IDs
+- Token payload is encoded, not encrypted (sensitive data shouldn't be included)
+
+## Alternatives Considered
+
+### Session-based Authentication
+
+Pros:
+- Well-established, traditional approach
+- Easy to implement and understand
+- Simple to revoke (delete the session)
+
+Cons:
+- Requires session storage on the server
+- Can be problematic in distributed/scaled environments
+- Typically relies on cookies which have cross-domain limitations
+
+### API Keys
+
+Pros:
+- Very simple to implement
+- Good for service-to-service communication
+- No expiration management needed
+
+Cons:
+- Not suitable for user authentication
+- Limited granularity for permissions
+- No built-in standard for claims or payload
+
+## Consequences
+
+### Positive
+
+- Simplified server architecture with no session storage requirements
+- Improved performance for authentication checks
+- Enhanced cross-domain and mobile app support
+- Ability to include standard claims (exp, iat, sub, etc.) in the token
+
+### Negative
+
+- Need to implement token refresh mechanism for long-lived sessions
+- Need for a token blacklist/revocation strategy
+- More complex client-side token management compared to cookies
+
+### Neutral
+
+- Need to carefully design token payload to balance size and information needs
+- Will use short-lived access tokens (15 minutes) with longer-lived refresh tokens (7 days)
+- Client applications must properly handle token storage and renewal
+
+## Implementation Notes
+
+- We will use the `jsonwebtoken` library for token creation and validation
+- Tokens will be signed with RS256 (asymmetric) algorithm
+- Access tokens will have a 15-minute expiration
+- Refresh tokens will have a 7-day expiration and be single-use
+- We will implement a token blacklist using Redis for immediate revocation when needed
+- Social login (OAuth) will use Passport.js strategies
+- Authentication middleware will validate tokens on protected routes
+
+## Related Decisions
+
+- ADR001: Chosen Database System
+- ADR003: API Security Measures (pending)
+
+## References
+
+- [JWT.io](https://jwt.io/)
+- [IETF RFC 7519 - JSON Web Token](https://tools.ietf.org/html/rfc7519)
+- [Auth0: JWTs vs Sessions](https://auth0.com/blog/cookies-vs-tokens-definitive-guide/)
+- [OWASP: JSON Web Token Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html)

package/claude-code/simone/.simone/99_TEMPLATES/adr_template.md

@@ -0,0 +1,49 @@
+---
+adr_id: ADR{{number}}
+title: "{{title}}"
+status: "proposed" # proposed | accepted | deprecated | superseded
+date: {{YYYY-MM-DD}}
+authors: ["{{author}}"]
+---
+
+# ADR{{number}}: {{title}}
+
+## Status
+
+{{status}} - {{YYYY-MM-DD}}
+
+## Context
+
+{{What is the issue that we're seeing that is motivating this decision or change?}}
+
+## Decision
+
+{{What is the change that we're proposing or have agreed to implement?}}
+
+## Consequences
+
+### Positive
+
+- {{e.g., improvement of quality attribute satisfaction, follows the architectural principles, ...}}
+
+### Negative
+
+- {{e.g., compromising quality attribute, follows the architectural principles, ...}}
+
+## Alternatives Considered
+
+### {{Alternative 1}}
+
+{{Description and reasoning for why this was not chosen}}
+
+### {{Alternative 2}}
+
+{{Description and reasoning for why this was not chosen}}
+
+## Implementation Notes
+
+{{Any specific implementation details, migration steps, or technical considerations}}
+
+## Related
+
+- {{Links to related ADRs, issues, or documentation}}

package/claude-code/simone/.simone/99_TEMPLATES/milestone_meta_template.md

@@ -0,0 +1,25 @@
+---
+milestone_id: M<ID>
+title: Milestone Title
+status: pending # pending | active | completed | blocked | on_hold
+last_updated: YYYY-MM-DD HH:MM
+---
+
+## Milestone: {{ title }}
+
+### Goals
+- Clearly define the primary objectives of this milestone.
+- What should be achieved by the end of this milestone?
+
+### Key Documents
+
+List the main requirement documents associated with this milestone (e.g., PRD, Technical Specifications).
+
+- `PRD_<Milestone_Name>.md`
+- `SPECS_<Milestone_Name>.md`
+
+### Definition of Done (DoD)
+- Specific, measurable criteria that must be met for this milestone to be considered complete.
+
+### Notes / Context (Optional)
+- Any additional context, high-level strategy, or important notes related to this milestone for Claude.

package/claude-code/simone/.simone/99_TEMPLATES/project_manifest_template.md

@@ -0,0 +1,39 @@
+---
+project_name: {{project_name}}
+current_milestone_id: {{current_milestone_id}}
+highest_sprint_in_milestone: {{highest_sprint_in_milestone}}
+current_sprint_id: {{current_sprint_id}}
+status: active
+last_updated: {{timestamp}}
+---
+
+# Project Manifest: {{project_name}}
+
+This manifest serves as the central reference point for the project. It tracks the current focus and links to key documentation.
+
+## 1. Project Vision & Overview
+
+{{project_vision}}
+
+This project follows a milestone-based development approach.
+
+## 2. Current Focus
+
+- **Milestone:** {{current_milestone_id}} - {{current_milestone_name}}
+- **Sprint:** {{current_sprint_id}} - {{current_sprint_name}}
+
+## 3. Sprints in Current Milestone
+
+{{sprint_list}}
+
+## 4. Key Documentation
+
+- [Architecture Documentation](./01_PROJECT_DOCS/ARCHITECTURE.md)
+- [Current Milestone Requirements](./02_REQUIREMENTS/{{current_milestone_id}}_{{current_milestone_slug}}/)
+- [General Tasks](./04_GENERAL_TASKS/)
+
+## 5. Quick Links
+
+- **Current Sprint:** [{{current_sprint_id}} Sprint Folder](./03_SPRINTS/{{current_sprint_id}}_{{current_milestone_id}}_{{current_sprint_slug}}/)
+- **Active Tasks:** Check sprint folder for T##_{{current_sprint_id}}_*.md files
+- **Project Reviews:** [Latest Review](./10_STATE_OF_PROJECT/)

package/claude-code/simone/.simone/99_TEMPLATES/sprint_meta_template.md

@@ -0,0 +1,23 @@
+---
+sprint_folder_name: S<SprintSequenceID>_M<MilestoneID>_<Short_Name>
+sprint_sequence_id: S<ID>
+milestone_id: M<ID>
+title: Sprint Title - Focus of this Sprint
+status: pending # pending | active | completed | aborted
+goal: Clearly state the primary objective of this sprint.
+last_updated: YYYY-MM-DDTHH:MM:SSZ
+---
+
+# Sprint: {{ title }} ({{ sprint_sequence_id }})
+
+## Sprint Goal
+{{ goal }}
+
+## Scope & Key Deliverables (Optional)
+- What specific features, fixes, or outcomes are targeted in this sprint for Claude to work on?
+
+## Definition of Done (for the Sprint) (Optional)
+- What conditions must be met for the sprint itself to be considered successfully completed?
+
+## Notes / Retrospective Points (Optional)
+- Any specific notes for this sprint.

package/claude-code/simone/.simone/99_TEMPLATES/task_template.md

@@ -0,0 +1,35 @@
+---
+task_id: T<TaskNN>_S<SprintSequenceID> # For Sprint Tasks (e.g., T01_S01) OR T<NNN> for General Tasks (e.g., T501)
+sprint_sequence_id: S<ID> # e.g., S01 (If part of a sprint, otherwise null or absent)
+status: open # open | in_progress | pending_review | done | failed | blocked
+complexity: Medium # Low | Medium | High
+last_updated: YYYY-MM-DDTHH:MM:SSZ
+---
+
+# Task: (Filename serves as the descriptive title)
+
+## Description
+Briefly explain what this task is about. Provide necessary context to understand the 'why' behind the task.
+
+## Goal / Objectives
+Clearly state what needs to be achieved by completing this task. What does success look like?
+- Objective 1
+- Objective 2
+
+## Acceptance Criteria
+Specific, measurable conditions that must be met for this task to be considered 'done'.
+- [ ] Criterion 1 is met.
+- [ ] Criterion 2 is verified.
+
+## Subtasks
+A checklist of smaller steps to complete this task.
+- [ ] Subtask 1
+- [ ] Subtask 2
+
+## Output Log
+*(This section is populated as work progresses on the task)*
+
+[YYYY-MM-DD HH:MM:SS] Started task
+[YYYY-MM-DD HH:MM:SS] Modified files: file1.js, file2.js
+[YYYY-MM-DD HH:MM:SS] Completed subtask: Implemented feature X
+[YYYY-MM-DD HH:MM:SS] Task completed

package/claude-code/simone/.simone/CLAUDE.MD

@@ -0,0 +1,65 @@
+# CLAUDE.md - Simone Framework Structure Guide
+
+## Overview
+This is the root directory of the Simone framework structure. It contains all project documentation, requirements, sprints, and organizational files.
+
+## Critical Files
+
+### Project Manifest
+**IMPORTANT**: The project manifest file MUST be named:
+```
+00_PROJECT_MANIFEST.md
+```
+
+**NOT**:
+- ❌ `MANIFEST.md`
+- ❌ `PROJECT_MANIFEST.md`
+- ❌ `project_manifest.md`
+
+The manifest is the central reference file that tracks:
+- Project name and status
+- Current milestone and sprint
+- Project metadata
+- Last updated timestamp
+
+## Directory Structure
+```
+.simone/
+├── 00_PROJECT_MANIFEST.md          # Central project reference (CORRECT NAME)
+├── 01_PROJECT_DOCS/                # General project documentation
+├── 02_REQUIREMENTS/                # Milestone-based requirements
+├── 03_SPRINTS/                     # Sprint execution folders
+├── 04_GENERAL_TASKS/               # Non-sprint tasks
+├── 05_ARCHITECTURAL_DECISIONS/     # ADR documentation
+├── 10_STATE_OF_PROJECT/            # Project review snapshots
+└── 99_TEMPLATES/                   # Document templates
+```
+
+## Naming Conventions Summary
+
+### Files
+- **Project Manifest**: `00_PROJECT_MANIFEST.md`
+- **Milestone Meta**: `M##_milestone_meta.md`
+- **Sprint Meta**: `S##_M##_sprint_meta.md`
+- **Task Files**: `TASK_##_*.md`
+- **ADR Files**: `ADR_###_*.md`
+
+### Folders
+- **Milestones**: `M##_Milestone_Name/`
+- **Sprints**: `S##_M##_Sprint_Name/`
+- **State Snapshots**: `YYYY-MM-DD_HH-MM_snapshot/`
+
+## Important Notes for Claude Code
+
+1. **Always create `00_PROJECT_MANIFEST.md`** when initializing a project
+2. **Use the templates** from `99_TEMPLATES/` for consistency
+3. **Follow the naming conventions exactly** - they enable proper sorting and navigation
+4. **Update the manifest** when creating milestones or sprints
+5. **Use underscores** for spaces in folder and file names
+
+## Common Initialization Mistakes
+- Creating `MANIFEST.md` instead of `00_PROJECT_MANIFEST.md`
+- Missing the leading zeros in numbered prefixes
+- Using hyphens instead of underscores
+- Creating files without using templates
+- Not updating the manifest after structural changes

package/claude-code/simone/.simone/README.md

@@ -0,0 +1,97 @@
+# Simone Framework
+
+Simone is a project management system designed to work with Claude Code's strengths and limitations. It provides structure for breaking down software projects into manageable, context-aware tasks.
+
+## Core Concept
+
+The fundamental challenge: AI context windows are limited and we can't control what information stays or leaves during long sessions. Simone solves this by starting fresh for each task while providing rich, relevant context.
+
+## How Simone Works
+
+### 1. Requirements First
+
+Projects begin with well-documented requirements and specifications:
+
+**In `01_PROJECT_DOCS/`:**
+
+- Architecture specifications (ARCHITECTURE.md is required)
+- Technical design documents
+- API specifications
+- Database schemas
+- Integration guides
+
+**In `02_REQUIREMENTS/`:**
+
+- Product Requirements Documents (PRDs) organized by milestone
+- Feature specifications
+- User stories and acceptance criteria
+
+Both directories work together to define what gets built and how.
+
+### 2. Structured Breakdown
+
+Work is organized hierarchically:
+
+- **Milestones** (M01, M02...) - Major project phases
+- **Sprints** (S01, S02...) - Focused work periods within milestones
+- **Tasks** (T01, T02...) - Atomic units of work
+
+### 3. Task Execution Flow
+
+Each task follows a strict workflow:
+
+1. Task selected from sprint or general tasks
+2. Status updated to `in_progress`
+3. Work performed following acceptance criteria
+4. Automatic code review against requirements
+5. Task marked `done` only after review passes
+6. File renamed with `TX` prefix to indicate completion
+
+### 4. Context Management
+
+For each task, Simone provides:
+
+- The specific task description and criteria
+- Relevant sprint and milestone context
+- Architecture and requirements documentation
+- Project manifest for current state awareness
+
+This ensures Claude has exactly what's needed without information overload.
+
+### 5. Quality Control
+
+Built-in review processes maintain standards:
+
+- **Code Review**: Every task completion triggers requirement validation
+- **Project Review**: Regular health checks create timestamped snapshots
+- **Zero Tolerance**: Any deviation from specifications fails review
+
+## Directory Purpose
+
+- `00_PROJECT_MANIFEST.md` - Current project state and focus
+- `01_PROJECT_DOCS/` - Technical foundation (architecture, APIs, schemas)
+- `02_REQUIREMENTS/` - Business requirements organized by milestone
+- `03_SPRINTS/` - Sprint organization and task definitions
+- `04_GENERAL_TASKS/` - Non-sprint specific tasks
+- `05_ARCHITECTURE_DECISIONS/` - ADRs for key decisions
+- `10_STATE_OF_PROJECT/` - Project review history
+- `99_TEMPLATES/` - Standardized file templates
+
+## Commands Overview
+
+Simone commands (`/project:simone:command`) automate the workflow:
+
+- Planning: `plan_milestone`, `create_sprint`
+- Execution: `create_task`, `do_task`, `code_review`
+- Maintenance: `commit`, `project_review`, `discuss_review`
+- Utilities: `initialize`
+
+## Key Principles
+
+1. **Fresh Context**: Each task starts with a clean slate
+2. **Focused Scope**: Tasks are sized for single-session completion
+3. **Rich Context**: Surrounding documentation guides development
+4. **Strict Validation**: Requirements are enforced, not suggested
+5. **Progressive Documentation**: Knowledge accumulates in structured form
+
+The result: Claude can always work confidently with full project awareness, regardless of session history.

package/claude-code/simone/CHANGELOG.md

@@ -0,0 +1,71 @@
+# Changelog
+
+## 2025-05-30
+
+### Added
+
+- `npx hello-simone` quick start command for easy Simone installation
+- Interactive, adaptive initialize command that:
+  - Auto-detects project type and framework
+  - Guides users through conversational setup
+  - Creates documentation through Q&A process
+  - Adapts to existing vs new projects
+
+### Changed
+
+- initialize command completely rewritten for better user experience
+- Removed complex branching logic in favor of adaptive process
+- Focus on conversational interaction rather than rigid steps
+
+### Improved
+
+- Better handling of existing documentation during setup
+- Smart project detection (Node.js, Python, PHP, etc.)
+- Milestone creation now interactive and context-aware
+
+## 2025-05-29
+
+### Added
+
+- ADR template for architecture decision records
+- Task ID filtering in commit command (T01_S02, TX003 patterns)
+- YOLO mode in commit command to skip user approval
+- Code review results now write to task Output Log sections
+- create_general_task command for structured task creation
+- create_sprint_tasks command for detailed sprint planning
+- create_sprints_from_milestone command for milestone-based sprint planning
+- prime command for quick project context loading
+- yolo command for autonomous task execution without user interaction
+
+### Changed
+
+- Date format simplified to YYYY-MM-DD HH:MM in templates
+- Milestone template heading structure updated
+- do_task command now uses parallel subagents and updates project manifest
+- project_review command removes timeline pressure and focuses on current state
+
+### Removed
+
+- create_sprint, create_task, plan_milestone commands (replaced by new workflow)
+
+## Developer Notes
+
+This update represents a significant evolution based on real-world usage and user feedback. The command architecture has been substantially enhanced with better use of parallel agents, loops, and conditionals, which work surprisingly well in practice.
+
+**Command Complexity**: The enhanced commands may behave differently between Claude Opus and Sonnet models. While the complexity might be challenging for Sonnet, testing suggests it should handle the workflows effectively.
+
+**Task Quality Improvements**: The new `create_sprint_tasks` and `create_general_task` commands now provide much better context and codebase references, resulting in notably higher quality task generation with specific implementation guidance.
+
+**YOLO Mode Warning**: The standalone `yolo` command requires extreme caution. It should only be used:
+
+- Within isolated development environments
+- With Claude Code's permission-skipping mode enabled (`claude --dangerously-skip-permissions`)
+- Never on production systems or systems with important data
+
+The YOLO mode can potentially modify or delete files outside your project directory. Use at your own risk and only in completely isolated environments.
+
+**Feedback Welcome**: Submit issues or pull requests on GitHub. This framework continues to evolve based on real-world usage patterns.
+
+## 2025-05-23
+
+Initial release of Simone framework

package/claude-code/simone/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 moonklabs
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.