aios-core 1.0.0

package/.aios-core/working-in-the-brownfield.md

@@ -0,0 +1,361 @@
+# Working in the Brownfield: A Complete Guide
+
+> **HIGHLY RECOMMENDED: Use Gemini Web or Gemini CLI for Brownfield Documentation Generation!**
+>
+> Gemini Web's 1M+ token context window or Gemini CLI (when its working) can analyze your ENTIRE codebase or critical sections of it all at once (obviously within reason):
+>
+> - Upload via GitHub URL or use gemini cli in the project folder
+> - If in the web: Upload up to 1000 files or the zipped project or just give it the github url
+
+## What is Brownfield Development?
+
+Brownfield development refers to adding features, fixing bugs, or modernizing existing software projects. Unlike greenfield (new) projects, brownfield work requires understanding existing code, respecting constraints, and ensuring new changes integrate seamlessly without breaking existing functionality.
+
+## When to Use AIOS for Brownfield
+
+- Add significant new features to existing applications
+- Modernize legacy codebases
+- Integrate new technologies or services
+- Refactor complex systems
+- Fix bugs that require architectural understanding
+- Document undocumented systems
+
+## When NOT to use a Brownfield Flow
+
+If you have just completed an MVP with AIOS, and you want to continue with post-MVP, its easier to just talk to the PM and ask him to work with you to create a new epic to add into the PRD, shard out the epic, update any architecture documents with the architect, and just go from there.
+
+## The Complete Brownfield Workflow
+
+### Choose Your Approach
+
+#### Approach A: PRD-First (Recommended if adding very large and complex new features, single or multiple epics or massive changes)
+
+**Best for**: Large codebases, monorepos, or when you know exactly what you want to build
+
+1. **Create PRD First** to define requirements
+2. **Document only relevant areas** based on PRD needs
+3. **More efficient** - avoids documenting unused code
+
+#### Approach B: Document-First (Good for Smaller Projects)
+
+**Best for**: Smaller codebases, unknown systems, or exploratory changes
+
+1. **Document entire system** first
+2. **Create PRD** with full context
+3. **More thorough** - captures everything
+
+### Approach A: PRD-First Workflow (Recommended)
+
+#### Phase 1: Define Requirements First
+
+**In Gemini Web (with your codebase uploaded):**
+
+```bash
+@pm
+*create-doc brownfield-prd
+```
+
+The PM will:
+
+- **Ask about your enhancement** requirements
+- **Explore the codebase** to understand current state
+- **Identify affected areas** that need documentation
+- **Create focused PRD** with clear scope
+
+**Key Advantage**: The PRD identifies which parts of your monorepo/large codebase actually need documentation!
+
+#### Phase 2: Focused Documentation
+
+**Still in Gemini Web, now with PRD context:**
+
+```bash
+@analyst
+*document-project
+```
+
+The analyst will:
+
+- **Ask about your focus** if no PRD was provided
+- **Offer options**: Create PRD, provide requirements, or describe the enhancement
+- **Reference the PRD/description** to understand scope
+- **Focus on relevant modules** identified in PRD or your description
+- **Skip unrelated areas** to keep docs lean
+- **Generate ONE architecture document** for all environments
+
+The analyst creates:
+
+- **One comprehensive architecture document** following fullstack-architecture template
+- **Covers all system aspects** in a single file
+- **Easy to copy and save** as `docs/project-architecture.md`
+- **Can be sharded later** in IDE if desired
+
+For example, if you say "Add payment processing to user service":
+
+- Documents only: user service, API endpoints, database schemas, payment integrations
+- Creates focused source tree showing only payment-related code paths
+- Skips: admin panels, reporting modules, unrelated microservices
+
+### Approach B: Document-First Workflow
+
+#### Phase 1: Document the Existing System
+
+**Best Approach - Gemini Web with 1M+ Context**:
+
+1. **Go to Gemini Web** (gemini.google.com)
+2. **Upload your project**:
+   - **Option A**: Paste your GitHub repository URL directly
+   - **Option B**: Upload up to 1000 files from your src/project folder
+   - **Option C**: Zip your project and upload the archive
+3. **Load the analyst agent**: Upload `dist/agents/analyst.txt`
+4. **Run documentation**: Type `*document-project`
+
+The analyst will generate comprehensive documentation of everything.
+
+#### Phase 2: Plan Your Enhancement
+
+#### Option A: Full Brownfield Workflow (Recommended for Major Changes)
+
+**1. Create Brownfield PRD**:
+
+```bash
+@pm
+*create-doc brownfield-prd
+```
+
+The PM agent will:
+
+- **Analyze existing documentation** from Phase 1
+- **Request specific enhancement details** from you
+- **Assess complexity** and recommend approach
+- **Create epic/story structure** for the enhancement
+- **Identify risks and integration points**
+
+**How PM Agent Gets Project Context**:
+
+- In Gemini Web: Already has full project context from Phase 1 documentation
+- In IDE: Will ask "Please provide the path to your existing project documentation"
+
+**Key Prompts You'll Encounter**:
+
+- "What specific enhancement or feature do you want to add?"
+- "Are there any existing systems or APIs this needs to integrate with?"
+- "What are the critical constraints we must respect?"
+- "What is your timeline and team size?"
+
+**2. Create Brownfield Architecture**:
+
+```bash
+@architect
+*create-doc brownfield-architecture
+```
+
+The architect will:
+
+- **Review the brownfield PRD**
+- **Design integration strategy**
+- **Plan migration approach** if needed
+- **Identify technical risks**
+- **Define compatibility requirements**
+
+#### Option B: Quick Enhancement (For Focused Changes)
+
+**For Single Epic Without Full PRD**:
+
+```bash
+@pm
+*brownfield-create-epic
+```
+
+Use when:
+
+- Enhancement is well-defined and isolated
+- Existing documentation is comprehensive
+- Changes don't impact multiple systems
+- You need quick turnaround
+
+**For Single Story**:
+
+```bash
+@pm
+*brownfield-create-story
+```
+
+Use when:
+
+- Bug fix or tiny feature
+- Very isolated change
+- No architectural impact
+- Clear implementation path
+
+### Phase 3: Validate Planning Artifacts
+
+```bash
+@po
+*execute-checklist po-master-checklist
+```
+
+The PO ensures:
+
+- Compatibility with existing system
+- No breaking changes planned
+- Risk mitigation strategies in place
+- Clear integration approach
+
+### Phase 4: Transition to Development
+
+Follow the enhanced IDE Development Workflow:
+
+1. **Ensure documents are in project**:
+
+   - Copy `docs/prd.md` (or brownfield-prd.md)
+   - Copy `docs/architecture.md` (or brownfield-architecture.md)
+
+2. **Shard documents**:
+
+   ```bash
+   @po
+   # Ask to shard docs/prd.md
+   ```
+
+3. **Development cycle**:
+   - **SM** creates stories with integration awareness
+   - **Dev** implements with existing code respect
+   - **QA** reviews for compatibility and improvements
+
+## Brownfield Best Practices
+
+### 1. Always Document First
+
+Even if you think you know the codebase:
+
+- Run `document-project` to capture current state
+- AI agents need this context
+- Discovers undocumented patterns
+
+### 2. Respect Existing Patterns
+
+The brownfield templates specifically look for:
+
+- Current coding conventions
+- Existing architectural patterns
+- Technology constraints
+- Team preferences
+
+### 3. Plan for Gradual Rollout
+
+Brownfield changes should:
+
+- Support feature flags
+- Plan rollback strategies
+- Include migration scripts
+- Maintain backwards compatibility
+
+### 4. Test Integration Thoroughly
+
+Focus testing on:
+
+- Integration points
+- Existing functionality (regression)
+- Performance impact
+- Data migrations
+
+### 5. Communicate Changes
+
+Document:
+
+- What changed and why
+- Migration instructions
+- New patterns introduced
+- Deprecation notices
+
+## Common Brownfield Scenarios
+
+### Scenario 1: Adding a New Feature
+
+1. Document existing system
+2. Create brownfield PRD focusing on integration
+3. Architecture emphasizes compatibility
+4. Stories include integration tasks
+
+### Scenario 2: Modernizing Legacy Code
+
+1. Extensive documentation phase
+2. PRD includes migration strategy
+3. Architecture plans gradual transition
+4. Stories follow strangler fig pattern
+
+### Scenario 3: Bug Fix in Complex System
+
+1. Document relevant subsystems
+2. Use `brownfield-create-story` for focused fix
+3. Include regression test requirements
+4. QA validates no side effects
+
+### Scenario 4: API Integration
+
+1. Document existing API patterns
+2. PRD defines integration requirements
+3. Architecture ensures consistent patterns
+4. Stories include API documentation updates
+
+## Troubleshooting
+
+### "The AI doesn't understand my codebase"
+
+**Solution**: Re-run `document-project` with more specific paths to critical files
+
+### "Generated plans don't fit our patterns"
+
+**Solution**: Update generated documentation with your specific conventions before planning phase
+
+### "Too much boilerplate for small changes"
+
+**Solution**: Use `brownfield-create-story` instead of full workflow
+
+### "Integration points unclear"
+
+**Solution**: Provide more context during PRD creation, specifically highlighting integration systems
+
+## Quick Reference
+
+### Brownfield-Specific Commands
+
+```bash
+# Document existing project
+@analyst → *document-project
+
+# Create enhancement PRD
+@pm → *create-doc brownfield-prd
+
+# Create architecture with integration focus
+@architect → *create-doc brownfield-architecture
+
+# Quick epic creation
+@pm → *brownfield-create-epic
+
+# Single story creation
+@pm → *brownfield-create-story
+```
+
+### Decision Tree
+
+```text
+Do you have a large codebase or monorepo?
+├─ Yes → PRD-First Approach
+│   └─ Create PRD → Document only affected areas
+└─ No → Is the codebase well-known to you?
+    ├─ Yes → PRD-First Approach
+    └─ No → Document-First Approach
+
+Is this a major enhancement affecting multiple systems?
+├─ Yes → Full Brownfield Workflow
+└─ No → Is this more than a simple bug fix?
+    ├─ Yes → brownfield-create-epic
+    └─ No → brownfield-create-story
+```
+
+## Conclusion
+
+Brownfield development with AIOS-Method provides structure and safety when modifying existing systems. The key is providing comprehensive context through documentation, using specialized templates that consider integration requirements, and following workflows that respect existing constraints while enabling progress.
+
+Remember: **Document First, Plan Carefully, Integrate Safely**

package/.claude/rules/mcp-usage.md

@@ -0,0 +1,176 @@
+---
+paths: **/*
+---
+
+# MCP Server Usage Rules - AIOS Architecture
+
+## MCP Governance
+
+**IMPORTANT:** All MCP infrastructure management is handled EXCLUSIVELY by the **DevOps Agent (@devops / Gage)**.
+
+| Operation | Agent | Command |
+|-----------|-------|---------|
+| Search MCP catalog | DevOps | `*search-mcp` |
+| Add MCP server | DevOps | `*add-mcp` |
+| List enabled MCPs | DevOps | `*list-mcps` |
+| Remove MCP server | DevOps | `*remove-mcp` |
+| Setup Docker MCP | DevOps | `*setup-mcp-docker` |
+
+Other agents (Dev, Architect, etc.) are MCP **consumers**, not administrators. If MCP management is needed, delegate to @devops.
+
+---
+
+## MCP Configuration Architecture
+
+AIOS uses Docker MCP Toolkit as the primary MCP infrastructure:
+
+### Direct in Claude Code (global ~/.claude.json)
+| MCP | Purpose |
+|-----|---------|
+| **playwright** | Browser automation, screenshots, web testing |
+| **desktop-commander** | Docker container operations via docker-gateway |
+
+### Inside Docker Desktop (via docker-gateway)
+
+| MCP | Purpose |
+|-----|---------|
+| **EXA** | Web search, research, company/competitor analysis |
+| **Context7** | Library documentation lookup |
+| **Apify** | Web scraping, Actors, social media data extraction |
+
+## CRITICAL: Tool Selection Priority
+
+ALWAYS prefer native Claude Code tools over MCP servers:
+
+| Task | USE THIS | NOT THIS |
+|------|----------|----------|
+| Read files | `Read` tool | docker-gateway |
+| Write files | `Write` / `Edit` tools | docker-gateway |
+| Run commands | `Bash` tool | docker-gateway |
+| Search files | `Glob` tool | docker-gateway |
+| Search content | `Grep` tool | docker-gateway |
+| List directories | `Bash(ls)` or `Glob` | docker-gateway |
+
+## desktop-commander (docker-gateway) Usage
+
+### ONLY use docker-gateway when:
+1. User explicitly says "use docker" or "use container"
+2. User explicitly mentions "Desktop Commander"
+3. Task specifically requires Docker container operations
+4. Accessing MCPs running inside Docker (EXA, Context7)
+5. User asks to run something inside a Docker container
+
+### NEVER use docker-gateway for:
+- Reading local files (use `Read` tool)
+- Writing local files (use `Write` or `Edit` tools)
+- Running shell commands on host (use `Bash` tool)
+- Searching files (use `Glob` or `Grep` tools)
+- Listing directories (use `Bash(ls)` or `Glob`)
+- Running Node.js or Python scripts on host (use `Bash` tool)
+
+## playwright MCP Usage
+
+### ONLY use playwright when:
+1. User explicitly asks for browser automation
+2. User wants to take screenshots of web pages
+3. User needs to interact with a website
+4. Task requires web scraping or testing
+5. Filling forms or clicking elements on web pages
+
+### NEVER use playwright for:
+- General file operations
+- Running commands
+- Anything not related to web browsers
+
+## EXA MCP Usage (via Docker)
+
+### Use EXA (mcp__docker-gateway__web_search_exa) for:
+1. Web searches for current information
+2. Research and documentation lookup
+3. Company and competitor research
+4. Finding code examples online
+
+### Access pattern:
+```
+mcp__docker-gateway__web_search_exa
+```
+
+## Context7 MCP Usage (via Docker)
+
+### Use Context7 for:
+1. Library documentation lookup
+2. API reference for packages/frameworks
+3. Getting up-to-date docs for dependencies
+
+### Access pattern:
+```
+mcp__docker-gateway__resolve-library-id
+mcp__docker-gateway__get-library-docs
+```
+
+## Apify MCP Usage (via Docker)
+
+### Use Apify for:
+1. Searching Actors in Apify Store (web scrapers, automation tools)
+2. Running web scrapers for social media (Instagram, TikTok, LinkedIn, etc.)
+3. Extracting data from e-commerce sites
+4. Automated data collection from any website
+5. RAG-enabled web browsing for AI context
+
+### Access pattern (7 tools available):
+
+```text
+mcp__docker-gateway__apify-slash-rag-web-browser  # RAG-enabled web browsing
+mcp__docker-gateway__search-actors                 # Search for Actors
+mcp__docker-gateway__call-actor                    # Run an Actor
+mcp__docker-gateway__fetch-actor-details           # Get Actor info/schema
+mcp__docker-gateway__get-actor-output              # Get results from Actor run
+mcp__docker-gateway__search-apify-docs             # Search Apify documentation
+mcp__docker-gateway__fetch-apify-docs              # Fetch documentation page
+```
+
+### When to use Apify vs other tools:
+| Task | Tool |
+|------|------|
+| General web search | EXA (`web_search_exa`) |
+| Scrape specific website | Apify (`call-actor`) |
+| Social media data extraction | Apify (use specialized Actors) |
+| Library documentation | Context7 |
+
+---
+
+## Rationale
+
+- **Native tools** execute on the LOCAL system (Windows/Mac/Linux)
+- **docker-gateway** executes inside Docker containers (Linux)
+- Using docker-gateway for local operations causes path mismatches and failures
+- Native tools are faster and more reliable for local file operations
+- EXA, Context7, and Apify run inside Docker for isolation and consistent environment
+- playwright runs directly for better browser integration with host system
+
+---
+
+## Known Issues
+
+### Docker MCP Secrets Bug (Dec 2025)
+
+**Issue:** Docker MCP Toolkit's secrets store and template interpolation do not work properly. Credentials set via `docker mcp secret set` are NOT passed to containers.
+
+**Symptoms:**
+- `docker mcp tools ls` shows "(N prompts)" instead of "(N tools)"
+- MCP server starts but fails authentication
+- Verbose output shows `-e ENV_VAR` without values
+
+**Workaround:** Edit `~/.docker/mcp/catalogs/docker-mcp.yaml` directly with hardcoded env values:
+```yaml
+{mcp-name}:
+  env:
+    - name: API_TOKEN
+      value: 'actual-token-value'
+```
+
+**Affected MCPs:** Any MCP requiring authentication (Apify, Notion, Slack, etc.)
+
+**Working MCPs:** EXA works because its key is in `~/.docker/mcp/config.yaml` under `apiKeys`
+
+For detailed instructions, see `*add-mcp` task or ask @devops for assistance.

package/LICENSE

@@ -0,0 +1,48 @@
+Commons Clause License Condition v1.0
+
+The Software is provided to you by the Licensor under the License,
+as defined below, subject to the following condition.
+
+Without limiting other conditions in the License, the grant of rights
+under the License will not include, and the License does not grant to
+you, the right to Sell the Software.
+
+For purposes of the foregoing, "Sell" means practicing any or all of
+the rights granted to you under the License to provide to third parties,
+for a fee or other consideration (including without limitation fees for
+hosting or consulting/support services related to the Software), a
+product or service whose value derives, entirely or substantially, from
+the functionality of the Software.
+
+Any license notice or attribution required by the License must also
+include this Commons Clause License Condition notice.
+
+---
+
+MIT License
+
+Copyright (c) 2025 AllFluence Inc. - AIOS Framework
+
+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.
+
+---
+
+Software: Synkra AIOS (AI-Orchestrated System for Full Stack Development)
+License: MIT
+Licensor: AllFluence Inc.