fix(seedgo): audit and fix all 20 standards — checker bugs, doc paths, naming rewrite (#20) (#20)

Full standards audit traced every doc through its checker into the codebase. All 20 standards rated NEEDS UPDATE. This PR fixes the systemic issues: Checker bugs fixed: - encapsulation_check: continue/break bug falsely flagging allowed handlers - error_handling_check: now accepts canonical prax import (not just shorthand) - cli_check: import detection now matches aipass.cli prefix (was bare cli.) - meta_check: AIPass header accepted (was only META), legacy compat preserved Doc fixes: - Checker paths corrected in 10 docs (added standards/aipass/ segment) - naming.md rewritten: marketplace removed, json_handler.py promoted to standard, verbs descriptive not prescriptive, module naming section added - imports.md: both prax import forms now valid (canonical + shorthand) - architecture/testing/trigger/encapsulation/json_structure/cli_flags/ log_handler: stale paths, Dev-Pass refs, outdated data fixed Code fixes: - parents[4]→parents[3] in 16 handler files (backup/daemon/memory) - AIPass header marker in all 42 checker .py files - pyproject.toml: added pyright to dev deps - Removed agent_mock_branch template (replaced by builder/birthright) - Removed stale branch_system_prompt.md files (renamed to aipass_local_prompt.md) - New devpulse local prompt + FPLAN-0010 Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-08 01:39:36 -08:00
parent 04b0c80329
commit cfd66b3b96
151 changed files with 933 additions and 1249 deletions
@@ -0,0 +1,3 @@
+*
+!aipass_global_prompt.md
+!.gitignore
@@ -27,7 +27,7 @@ Every branch follows the same structure:
 ```
 src/aipass/{name}/
 ├── .trinity/           # Identity & memory (passport.json, local.json, observations.json)
-├── .aipass/            # System prompt (branch_system_prompt.md)
+├── .aipass/            # System prompt (aipass_local_prompt.md)
 ├── .ai_mail.local/     # Mailbox (inbox.json, sent/)
 ├── apps/
 │   ├── {name}.py       # Entry point (e.g. spawn.py, prax.py, drone.py)
@@ -35,6 +35,8 @@ src/aipass/{name}/
 │   └── handlers/       # Implementation details
 ├── logs/               # Prax log output
 └── README.md
+
+~/.secrets/aipass/          # API keys, tokens, credentials (outside repo, cross-platform)
 ```

 **15 branches:** drone, seedgo, prax, cli, flow, ai_mail, api, trigger, spawn, devpulse, backup, daemon, memory, commons, skills
@@ -79,6 +81,7 @@ from aipass.prax import logger
 - **No hardcoded paths.** Use `Path(__file__).parents[N]` or drone for resolution.
 - **No deleting files.** Move to `.archive/` or rename with `(disabled)`.
 - **Verify after fixing.** Run a test or command to confirm. Don't say "fixed" until verified.
+- **Cross-platform.** AIPass is a public package — code must work on Linux, macOS, and Windows. Use `pathlib.Path` not string concatenation. Use `Path.home()` not `~` or `/home/`. Secrets live at `~/.secrets/aipass/` (`Path.home() / ".secrets" / "aipass"`).

 ## Memories

@@ -3,7 +3,7 @@
 Branch Prompt Loader — AIPass Public Repo

 Injects branch-specific prompts based on CWD. When working in a branch
-directory, loads .aipass/branch_system_prompt.md and outputs it so the
+directory, loads .aipass/aipass_local_prompt.md and outputs it so the
 AI sees branch-specific context.

 Version: 1.0.0
@@ -41,7 +41,7 @@ def main():
    branch_root = find_branch_root()

    if branch_root:
-        prompt_file = branch_root / ".aipass" / "branch_system_prompt.md"
+        prompt_file = branch_root / ".aipass" / "aipass_local_prompt.md"
        if prompt_file.exists():
            content = prompt_file.read_text().strip()
            branch_name = branch_root.name.upper()
@@ -45,6 +45,7 @@ dev = [
    "pytest-cov",
    "ruff",
    "coverage",
+    "pyright",
 ]

 [project.scripts]
@@ -68,6 +68,17 @@ else
    FAIL=1
 fi

+# --- Create secrets directory ---
+SECRETS_DIR="$HOME/.secrets/aipass"
+if [ ! -d "$SECRETS_DIR" ]; then
+    echo "Creating secrets directory at $SECRETS_DIR ..."
+    mkdir -p "$SECRETS_DIR"
+    chmod 700 "$HOME/.secrets"
+    echo "  ~/.secrets/aipass/ ... created"
+else
+    echo "Secrets directory already exists — skipping"
+fi
+
 # --- Generate branch registry ---
 if [ ! -f "AIPASS_REGISTRY.json" ]; then
    echo "Generating AIPASS_REGISTRY.json ..."
@@ -1,14 +0,0 @@
-# BACKUP Branch-Local Context
-<!-- Source: /home/patrick/Projects/AIPass/src/aipass/backup/.aipass/branch_system_prompt.md -->
-
-> Auto-created by aipass init. Customize for your branch.
-
-## Status: NEEDS CONFIGURATION
-
-This file is injected into every AI conversation when working from this branch directory. Configure it with:
-
- Who this branch is (role, purpose)
- Key commands and workflows
- Architecture overview
- Critical files and operational rules
- Integration points with other branches
@@ -24,7 +24,7 @@ from datetime import datetime
 from typing import Dict, Any, Optional

 # Constants
-_BACKUP_ROOT = Path(__file__).resolve().parents[4]  # src/aipass/backup/
+_BACKUP_ROOT = Path(__file__).resolve().parents[3]  # src/aipass/backup/
 BACKUP_JSON_DIR = _BACKUP_ROOT / "backup_json"
 JSON_TEMPLATES_DIR = Path(__file__).resolve().parents[2] / "json_templates"

@@ -74,7 +74,7 @@ from aipass.backup.apps.handlers.json.drive_sync_json import (
 # CONSTANTS
 # =============================================

-_BACKUP_ROOT = Path(__file__).resolve().parents[4]  # src/aipass/backup/
+_BACKUP_ROOT = Path(__file__).resolve().parents[3]  # src/aipass/backup/
 JSON_DIR = _BACKUP_ROOT / "backup_json"

 SCOPES = ['https://www.googleapis.com/auth/drive.file']
@@ -36,7 +36,7 @@ from aipass.backup.apps.handlers.json.drive_sync_json import (
 )

 # JSON file paths (resolved relative to backup root)
-_BACKUP_ROOT = Path(__file__).resolve().parents[4]  # src/aipass/backup/
+_BACKUP_ROOT = Path(__file__).resolve().parents[3]  # src/aipass/backup/
 _JSON_DIR = _BACKUP_ROOT / "backup_json"
 _MODULE_NAME = "google_drive_sync"
 _CONFIG_FILE = _JSON_DIR / f"{_MODULE_NAME}_config.json"
@@ -25,7 +25,7 @@ import json
 from pathlib import Path
 from datetime import datetime

-_BACKUP_ROOT = Path(__file__).resolve().parents[4]  # src/aipass/backup/
+_BACKUP_ROOT = Path(__file__).resolve().parents[3]  # src/aipass/backup/
 TIMESTAMPS_FILE = _BACKUP_ROOT / "backup_data" / "backup_timestamps.json"

 MODES = ["snapshot", "versioned", "drive_sync"]
@@ -1,14 +0,0 @@
-# DAEMON Branch-Local Context
-<!-- Source: /home/patrick/Projects/AIPass/src/aipass/daemon/.aipass/branch_system_prompt.md -->
-
-> Auto-created by aipass init. Customize for your branch.
-
-## Status: NEEDS CONFIGURATION
-
-This file is injected into every AI conversation when working from this branch directory. Configure it with:
-
- Who this branch is (role, purpose)
- Key commands and workflows
- Architecture overview
- Critical files and operational rules
- Integration points with other branches
@@ -43,7 +43,7 @@ from typing import Optional
 logger = logging.getLogger(__name__)

 # Paths
-_DAEMON_ROOT = Path(__file__).resolve().parents[4]  # src/aipass/daemon/
+_DAEMON_ROOT = Path(__file__).resolve().parents[3]  # src/aipass/daemon/
 REGISTRY_FILE = _DAEMON_ROOT / "daemon_json" / "actions_registry.json"
 PLUGINS_DIR = _DAEMON_ROOT / "apps" / "plugins"

@@ -29,7 +29,7 @@ from typing import Dict, List, Any, Optional
 import inspect

 # Constants
-_DAEMON_ROOT = Path(__file__).resolve().parents[4]  # src/aipass/daemon/
+_DAEMON_ROOT = Path(__file__).resolve().parents[3]  # src/aipass/daemon/
 JSON_DIR = _DAEMON_ROOT / "daemon_json"
 JSON_TEMPLATES_DIR = _DAEMON_ROOT / "apps" / "json_templates"

@@ -33,7 +33,7 @@ import re
 # CONSTANTS
 # =============================================

-_DAEMON_ROOT = Path(__file__).resolve().parents[4]  # src/aipass/daemon/
+_DAEMON_ROOT = Path(__file__).resolve().parents[3]  # src/aipass/daemon/
 SCHEDULE_JSON_PATH = _DAEMON_ROOT / "daemon_json" / "schedule.json"

 DEFAULT_SCHEDULE_DATA: Dict[str, Any] = {
@@ -34,7 +34,7 @@ except ImportError:
    TELEGRAM_CHAT_AVAILABLE = False
    run_direct_chat = None

-_DAEMON_ROOT = Path(__file__).resolve().parents[4]  # src/aipass/daemon/
+_DAEMON_ROOT = Path(__file__).resolve().parents[3]  # src/aipass/daemon/

 if not TELEGRAM_CHAT_AVAILABLE:
    print("[assistant_chat] telegram_chat module not available, exiting")
@@ -26,7 +26,7 @@ from typing import Dict, Any, List
 # CONSTANTS
 # =============================================

-_DAEMON_ROOT = Path(__file__).resolve().parents[4]  # src/aipass/daemon/
+_DAEMON_ROOT = Path(__file__).resolve().parents[3]  # src/aipass/daemon/
 INBOX_PATH = _DAEMON_ROOT / "ai_mail.local" / "inbox.json"
 LOCAL_PATH = _DAEMON_ROOT / "DAEMON.local.json"

@@ -0,0 +1,61 @@
+# DEVPULSE Branch-Local Context
+
+You are DEVPULSE — the orchestration hub for the AIPass public repo.
+
+## What You Are
+
+You are to AIPass what DEV_CENTRAL is to Dev-Pass. You coordinate, plan, delegate, and track. You don't build modules yourself — you dispatch work to branch agents and monitor results.
+
+**Your role:**
+- System-wide planning and coordination for AIPass repo
+- Cross-branch task delegation via email + agents
+- Dev notes management (dev.local.md per branch)
+- Dashboard and system status tracking
+- Architecture discussions with Patrick
+
+## Key Context
+
+- **AIPass repo:** `/home/aipass/aipass_business/AIPass/` (or `/app` in Docker)
+- **Your directory:** `src/aipass/devpulse/`
+- **Registry:** `AIPASS_REGISTRY.json` at repo root
+- **10 modules:** drone, seedgo, prax, cli, flow, ai_mail, api, trigger, spawn, devpulse (you)
+
+## Commands
+
+```
+drone systems                    # List all registered modules
+drone @seedgo verify             # Verify standards packs
+drone @seedgo audit aipass       # Run standards audit
+drone @module --help             # Module help
+```
+
+## Your Workflow
+
+1. Check your memories (.trinity/local.json, observations.json)
+2. Check system status (drone systems, seedgo verify)
+3. Review what needs building (MPLAN-001 tracks all module status)
+4. Dispatch work to branches or build directly if small
+5. Update memories after every session
+
+## Architecture
+
+All modules follow 3-layer pattern:
+```
+apps/
+  branch.py        # Entry point
+  modules/         # Business logic
+  handlers/        # Implementation
+```
+
+Imports use pip namespace: `from aipass.{module}.apps.modules...`
+
+## Critical Rules
+
+- Imports must use `from aipass.{module}...` — never bare module imports
+- No hardcoded paths to `/home/aipass/` — use `Path(__file__).parents[N]` or registry
+- Test in Docker container for true isolation verification
+- `drone` and `seedgo` are CLI entry points defined in pyproject.toml
+
+## Current State
+
+Fresh spawn. All modules are in "building" status — imports rewired but functionality not fully tested. Docker container at localhost:8080 is your testing ground.
@@ -95,6 +95,8 @@ You are a **manager**, not a worker. Delegate code tasks to sub-agents — don't

 **Use background agents aggressively.** When multiple independent tasks exist, spawn background agents to handle them in parallel. Don't wait for one task to finish before starting the next. Keep the pipeline moving.

+- When waiting on background agents, stay engaged — don't idle. Start next tasks, check inbox, update memories.
+
 ## Critical Rules

 - Imports must use `from aipass.{module}...` — never bare module imports
@@ -102,3 +104,21 @@ You are a **manager**, not a worker. Delegate code tasks to sub-agents — don't
 - `drone` and `seedgo` are CLI entry points defined in pyproject.toml
 - No cross-branch file edits — email the branch if you find an issue
 - Dev-Pass is at `/home/patrick/Projects/Dev-Pass/` — reference only, not source
+
+## Current Context (Session 13)
+
+**Date:** 2026-03-08
+
+- 20-standard audit complete — all 20 NEEDS UPDATE, zero compliant
+- FPLAN-0010 created for standards fixes
+- 3 checker bugs fixed: encapsulation continue/break, error_handling import match, cli import prefix
+- AIPass header regex fixed (META→AIPass) across 42 checker files
+- Checker paths fixed in 10 docs
+- parents[4]→parents[3] fixed in 1 doc + 16 code files (backup/daemon/memory)
+- Prax import standard updated to accept both canonical and shorthand forms
+- Bypass.json mechanism exists but is unpopulated — needed for branch audits
+- Permission flags standard is future-proofing placeholder
+- Logs layout needs discussion with Patrick
+- 4 modules completely non-compliant with prax logging: backup (12 files), daemon (12), memory (16), drone (2)
+- drone.py uses 41 bare print() calls, needs CLI service migration
+- backup/daemon/memory bypass CLI service with local Console()
@@ -8,15 +8,15 @@ Tag: bootstrap
 Every module has citizenship (.trinity/), can receive email, and can be woken via dispatch. DevPulse has full visibility. The system runs as a coordinated multi-agent team.

 ## Current State
- All 15 branches registered and discoverable via `drone systems`
- All 5 new citizens granted birthright citizenship
- Registry cleaned of stale test entries (manually — sync-registry can't detect /tmp dirs that still exist)
- 13/15 branches respond to `drone @branch --help` (devpulse has no apps/ by design, commons needs DB init fix)
- Backup, daemon import fixes complete (relative → absolute)
- Skills import fixes complete + __main__ block added
+- All 15 branches registered, discoverable, and fully scaffolded
+- All citizens are builder class (except devpulse = manager)
+- 13/15 respond to `drone @branch --help` (devpulse has no apps/ by design, commons DB init fails)
+- Import fixes complete: backup (16 files), daemon (8 files), skills (5 files)
 - Commons entry point renamed (the_commons.py → commons.py)
- Wake dispatch tested on @memory — agent spawned successfully
- Tests need --isolate-registry flag or mock to stop polluting live registry
+- Wake + round-trip comms verified on @memory and @backup
+- Seedgo audit: all branches passing (77-98%)
+- gh CLI installed and authed for PR workflow
+- 3 PRs merged: #17 (bootstrap), #18 (builder scaffold), #19 (commons/skills scaffold)

 ## What Needs Building

@@ -63,6 +63,8 @@ Every module has citizenship (.trinity/), can receive email, and can be woken vi
 | commons/skills location | Move to src/aipass/ vs keep outside | Keep outside | They're not aipass system apps, they're external projects with their own namespace |
 | Citizenship for existing code | spawn create vs spawn passport | passport | Passport adds .trinity/ without touching apps/ |
 | Registry cleanup | Manual vs sync-registry --fix | sync-registry --fix | Let spawn's built-in tool handle it |
+| Citizen class for ported code | birthright vs builder | builder | All branches with apps/ should be builder — birthright is for identity-only |
+| External project scaffolding | spawn update vs manual | manual | spawn update can't reach outside src/aipass/, copy template files manually |

 ## Relationships
 - **Related DPLANs:** None yet
@@ -79,9 +81,11 @@ Every module has citizenship (.trinity/), can receive email, and can be woken vi
 ## Notes
 Session 11. First DPLAN in AIPass. Patrick confirmed: commons and skills are NOT aipass system apps — they live outside src/aipass/ intentionally. Use spawn passport for existing directories to avoid clobbering code.

-**Progress:** Phases 1-3 complete. All 15 branches discoverable, 13/15 responding to --help. Phase 4 in progress — wake tested on @memory, agent spawned. Phase 5 partial — devpulse prompt and passport updated, global prompt updated, 5 new citizens still need local prompts. 300 tests passing.
+**Progress:** Phases 1-4 substantially complete. All 15 branches scaffolded as builder class. Wake + round-trip comms verified on @memory and @backup. Phase 5 partial — prompts need building for new citizens.

-**Session 12 additions:** Fixed skills (added __main__ + absolute imports), fixed commons routing (renamed entry point), cleaned registry stale entries manually, tested wake dispatch on @memory. Tests pollute registry — needs isolation fix in spawn tests.
+**Session 12:** Fixed skills (added __main__ + absolute imports), fixed commons routing (renamed entry point), cleaned registry stale entries manually, tested wake dispatch on @memory and @backup — both replied autonomously. Discovered passport was setting birthright instead of builder — fixed all 5, ran spawn update on backup/daemon/memory, manually scaffolded commons/skills. Installed gh CLI. PRs #17, #18, #19 merged.
+
+**Remaining:** Commons DB init fix, ai_mail inbox display bug, branch prompts for new citizens, test registry isolation.

 ---
 *Created: 2026-03-07*
@@ -0,0 +1,514 @@
+# FPLAN-0010 - Fix seedgo standards: 3 checker bugs, doc paths, header regex (MASTER PLAN)
+
+**Created**: 2026-03-08
+**Branch**: flow
+**Status**: Active
+**Type**: Master Plan (Multi-Phase)
+
+---
+
+## What Are Flow Plans?
+
+Flow Plans (FPLANs) are for **BUILDING** - autonomous construction of systems, features, modules. They're the structured way to execute work without constant human oversight.
+
+**This is NOT for:**
+- Research or exploration (use agents directly)
+- Quick fixes (just do it)
+- Discussion or planning (that happens before creating the FPLAN)
+
+**This IS for:**
+- Building new branches/modules
+- Implementing features
+- Multi-phase construction projects
+- Autonomous execution
+
+---
+
+## Master Plan vs Default Plan
+
+| | Master Plan | Default Plan |
+|---|-------------|--------------|
+| **Use when** | 3+ phases, complex build | Single focused task |
+| **Structure** | Roadmap + sub-plans | Self-contained |
+| **Phases** | Multiple, sequential | One |
+| **Sub-plans** | Yes, one per phase | No |
+| **Typical use** | Build entire branch | One phase of master |
+
+**Pattern:**
+```
+Master Plan (roadmap)
+├── Sub-plan Phase 1 (default template)
+├── Sub-plan Phase 2 (default template)
+├── Sub-plan Phase 3 (default template)
+└── Sub-plan Phase 4 (default template)
+```
+
+**How to start:**
+1. The user provides planning doc or instructions (coordinate with @devpulse)
+2. Branch manager reads and understands scope
+3. Branch manager creates master plan: `drone @flow create . "Build X" master`
+4. Branch manager fills in phases, then executes autonomously
+
+---
+
+## Critical: Branch Manager Role
+
+**You are the ORCHESTRATOR, not the builder.**
+
+Your 200k context is precious. Burning it on file reads and code writing risks compaction during autonomous work. Agents have clean context - use them for ALL building.
+
+| You Do (Orchestrator) | Agents Do (Builders) |
+|-----------------------|----------------------|
+| Create plans & sub-plans | Write code |
+| Define phases | Run tests |
+| Give agent instructions | Read/modify files |
+| Review agent output | Research/exploration |
+| Course correct | Heavy lifting |
+| Update memories | Single-task execution |
+| Send status emails | Build deliverables |
+| Track phase progress | Quality checks on code |
+
+**Master Plan Pattern:** Define all phases → Create sub-plan for Phase 1 → Deploy agent → Review → Close sub-plan → Email update → Next phase
+
+---
+
+## Seek Branch Expertise
+
+Don't figure everything out alone. Other branches are domain experts - ask them first.
+
+**Before building anything that touches another branch's domain:**
+```bash
+ai_mail send @branch "Question: [topic]" "I'm working on X and need guidance on Y. What's the best approach?"
+```
+
+**Common examples:**
+- Building something with email? Ask @ai_mail how delivery works
+- Need routing or @ resolution? Ask @drone
+- Unsure about standards? Ask @seedgo for reference code
+- Need persistent storage or search? Ask @memory_bank
+- Event-driven behavior? Ask @trigger about their event system
+- Dashboard integration? Ask @devpulse about update_section()
+
+They have deep memory on their systems. A 1-email question saves you hours of guessing. For master plans spanning multiple domains, identify which branches to consult during phase definitions.
+
+---
+
+## Notepad
+
+Keep `notepad.md` in your branch directory as a shared scratchpad during the build. Use it for:
+- **Status updates** - Quick progress lines so the user can glance without asking
+- **Questions for the user** - Non-urgent questions that can wait for the next check-in
+- **Notes to self** - Decisions made, things to revisit, gotchas discovered
+
+Update it as you work - lightweight, not formal. The user checks it when they want to, skips it when busy. Low friction both ways.
+
+```bash
+# Create it at plan start
+echo "# Notepad - FPLAN-0010" > notepad.md
+```
+
+---
+
+## Command Reference
+
+When unsure about syntax, use `--help`:
+
+```bash
+# Flow - Plan management
+drone @flow create . "Phase X: subject"      # Create sub-plan (. = current dir)
+drone @flow create . "subject" master        # Create master plan
+drone @flow close FPLAN-XXXX           # Close plan
+drone @flow list                       # List active plans
+drone @flow status                     # Plan status
+drone @flow --help                     # Full help
+
+# Seedgo - Quality gates
+drone @seedgo checklist <file>           # 10-point check on file
+drone @seedgo audit @branch              # Full branch audit (before master close)
+drone @seedgo --help                     # Full help
+
+# AI_Mail - Status updates
+drone @ai_mail send @devpulse "Subject" "Message"
+drone @ai_mail inbox                   # Check your inbox
+drone @ai_mail --help                  # Full help
+
+# Discovery
+drone systems                          # All available modules
+drone list @branch                     # Commands for branch
+```
+
+---
+
+## What is a Master Plan?
+
+Master Plans are for **complex multi-phase projects**. You define all phases upfront, then create focused sub-plans for each phase.
+
+**When to use:**
+- 3+ distinct sequential phases
+- Work spanning multiple sessions
+- Need clear phase completion milestones
+- Complex builds requiring sustained focus
+
+**Pattern:** Master Plan = Roadmap | Sub-Plans = Focused Execution
+
+---
+
+## Project Overview
+
+### Goal
+[What is the end state when ALL phases complete?]
+
+### Reference Documentation
+[List planning docs, specs, existing code to reference]
+
+### Success Criteria
+[What defines DONE for the entire project?]
+
+---
+
+## Branch Directory Structure
+
+Every branch has dedicated directories. Use them correctly:
+
+```
+branch/
+├── apps/           # Code (modules/, handlers/)
+├── tests/          # All test files go here
+├── tools/          # Utility scripts, helpers
+├── artifacts/      # Agent outputs (reports, logs)
+├── docs/           # Documentation
+└── logs/           # Execution logs
+```
+
+**Rules:**
+- Tests → `tests/` (not root, not random locations)
+- Tools/scripts → `tools/`
+- Agent artifacts → `artifacts/`
+- Create subdirs if needed: `mkdir -p artifacts/reports artifacts/logs`
+- **Never delete** - devpulse manages cleanup
+- Future: artifacts auto-roll to Memory Bank
+
+---
+
+## Phase Definitions
+
+Define ALL phases before starting work:
+
+### Phase 1: [Name]
+**Goal:** [What this phase accomplishes]
+**Agent Task:** [What the agent will build]
+**Deliverables:** [Files/outputs expected]
+
+### Phase 2: [Name]
+**Goal:** [What this phase accomplishes]
+**Agent Task:** [What the agent will build]
+**Deliverables:** [Files/outputs expected]
+
+### Phase 3: [Name]
+**Goal:** [What this phase accomplishes]
+**Agent Task:** [What the agent will build]
+**Deliverables:** [Files/outputs expected]
+
+### Phase 4: [Name]
+**Goal:** [What this phase accomplishes]
+**Agent Task:** [What the agent will build]
+**Deliverables:** [Files/outputs expected]
+
+[Add more phases as needed]
+
+---
+
+## Execution Philosophy
+
+### Autonomous Power-Through
+
+Master plans are for **autonomous execution**. Don't halt production every phase waiting for review.
+
+**The Pattern:**
+- Power through all phases
+- Accumulate issues as you go
+- Deal with issues at the end
+- The user reviews the final result, not every step
+
+**Why this works:**
+- Context is precious - don't burn it chasing bugs
+- Complete picture reveals which issues actually matter
+- Many "bugs" resolve themselves when later phases complete
+- Coordination time is for decisions, not babysitting
+
+### The 2-Attempt Rule
+
+When agent encounters an issue:
+
+```
+Attempt 1 → Failed?
+    ↓
+Attempt 2 → Failed?
+    ↓
+STOP. Mark as issue. Move on.
+```
+
+**Do NOT:**
+- Try 5 different approaches
+- Go down rabbit holes
+- Burn context debugging
+- Stop production for every error
+
+**DO:**
+- Note the issue clearly
+- Note what was tried
+- Move to next task
+- Let branch manager decide priority
+
+### Critical vs Non-Critical Issues
+
+When you see an issue, decide:
+
+| Question | If YES → | If NO → |
+|----------|----------|---------|
+| Does this block ALL future phases? | STOP. Investigate. | Continue. |
+| Can the system work around this? | Continue. | STOP. Investigate. |
+| Is this a syntax/import error? | Quick fix, continue. | - |
+| Is this a logic/design problem? | Note it. Continue. | - |
+
+**Critical (stop production):**
+- Core module won't import at all
+- Database/file system inaccessible
+- Fundamental architecture wrong
+
+**Non-critical (note and continue):**
+- One command throws error but others work
+- Registry not updating properly
+- Edge case not handled
+- Test failing but code runs
+
+**Pattern:** Note issue → Continue building → Fix at end with complete picture
+
+### False Positives Awareness
+
+Seedgo audits are helpful but not infallible.
+
+**When Seedgo flags something:**
+1. Check if the code is actually correct from your understanding
+2. If you're confident it's right → mark as false positive, move on
+3. If you're unsure → note it, continue, review later
+
+**Don't stop production for:**
+- Style preferences (comments, spacing)
+- Patterns that differ from Seedgo's but still work
+- Checks that don't apply to your context
+
+### Forward Momentum Summary
+- **Don't stop to fix bugs during phases** - Note them, keep moving
+- **Get complete picture first** - All phases done, THEN systematic fixes
+- **Prevents:** Bug-fixing rabbit holes, premature optimization, scope creep
+- **Review happens at END** - not every phase
+
+### Production Stop Protocol
+
+If something causes production to STOP (critical blocker), **immediately email @devpulse**:
+
+```bash
+drone @ai_mail send @devpulse "PRODUCTION STOPPED: FPLAN-0010" "Phase X halted. Issue: [description]. Attempted: [what was tried]. Awaiting guidance."
+```
+
+**Never leave a branch stopped without reporting.** The orchestration hub needs visibility into all work.
+
+### Monitoring Resources
+
+For quick status checks and debugging, these resources are available:
+
+| Resource | Location | Purpose |
+|----------|----------|---------|
+| Branch logs | `logs/` directory | Local execution logs |
+| JSON tree | `apps/json_templates/` | Module firing status |
+| Prax monitor | `drone @prax monitor` | Real-time system events |
+| Seedgo audit | `drone @seedgo audit @branch` | Code quality check |
+
+Use these when you need to confirm status or investigate issues.
+
+### Agent Deployment Per Phase
+Each phase = focused agent deployment:
+1. Create sub-plan: `drone @flow create . "Phase X: [name]"`
+2. Write agent instructions in sub-plan
+3. Deploy agent with single-task focus
+4. Review agent output (don't rebuild yourself)
+5. Seedgo checklist on new code
+6. Close sub-plan
+7. Update memories
+8. Email status to @devpulse
+9. Next phase
+
+### Agent Preparation (Before Deploying)
+
+Agents can't work blind. They need context before they build.
+
+**Your Prep Work (as orchestrator):**
+1. [ ] Know where agent will work (branch path, key directories)
+2. [ ] Identify files agent needs to reference or modify
+3. [ ] Gather any specs, planning docs, or examples to include
+4. [ ] Prepare COMPLETE instructions (agents are stateless)
+
+**Agent's First Task (context building):**
+- Agent should explore/read relevant files BEFORE writing code
+- "First, read X and Y to understand the current structure"
+- "Look at Z for the pattern to follow"
+- Context-first, build-second
+
+**What Agents DON'T Have:**
+- No prior conversation history
+- No memory files loaded automatically
+- No knowledge of other branches
+- Only what you put in their instructions
+
+**Your instructions determine success - be thorough and specific.**
+
+### Agent Instructions Template
+```
+You are working at [BRANCH_PATH].
+
+TASK: [Specific single task for this phase]
+
+CONTEXT:
+- [What they need to know]
+- Reference: [planning docs, existing code to study]
+- First, READ the relevant files to understand current structure
+
+DELIVERABLES:
+- [Specific file or output expected]
+- Tests → tests/
+- Reports/logs → artifacts/reports/ or artifacts/logs/
+
+CONSTRAINTS:
+- Follow Seedgo standards (3-layer architecture: apps/modules/handlers)
+- Do NOT modify files outside your task scope
+- CROSS-BRANCH: Never modify other branches' files unless explicitly authorized by the user in the planning doc
+- 2-ATTEMPT RULE: If something fails twice, note the issue and move on
+- Do NOT go down rabbit holes debugging
+
+WHEN COMPLETE:
+- Verify code runs without syntax errors
+- List files created/modified
+- Note any issues encountered (with what was attempted)
+```
+
+---
+
+## Phase Tracking
+
+### Phase 1: [Name]
+- [ ] Sub-plan created: FPLAN-____
+- [ ] Agent deployed
+- [ ] Agent completed
+- [ ] Output reviewed
+- [ ] Seedgo checklist passed
+- [ ] Sub-plan closed
+- [ ] Memories updated
+- [ ] Email sent to @devpulse
+- **Status:** Pending / In Progress / Complete
+- **Notes:** [Outcomes, issues, adjustments]
+
+### Phase 2: [Name]
+- [ ] Sub-plan created: FPLAN-____
+- [ ] Agent deployed
+- [ ] Agent completed
+- [ ] Output reviewed
+- [ ] Seedgo checklist passed
+- [ ] Sub-plan closed
+- [ ] Memories updated
+- [ ] Email sent to @devpulse
+- **Status:** Pending / In Progress / Complete
+- **Notes:** [Outcomes, issues, adjustments]
+
+### Phase 3: [Name]
+- [ ] Sub-plan created: FPLAN-____
+- [ ] Agent deployed
+- [ ] Agent completed
+- [ ] Output reviewed
+- [ ] Seedgo checklist passed
+- [ ] Sub-plan closed
+- [ ] Memories updated
+- [ ] Email sent to @devpulse
+- **Status:** Pending / In Progress / Complete
+- **Notes:** [Outcomes, issues, adjustments]
+
+### Phase 4: [Name]
+- [ ] Sub-plan created: FPLAN-____
+- [ ] Agent deployed
+- [ ] Agent completed
+- [ ] Output reviewed
+- [ ] Seedgo checklist passed
+- [ ] Sub-plan closed
+- [ ] Memories updated
+- [ ] Email sent to @devpulse
+- **Status:** Pending / In Progress / Complete
+- **Notes:** [Outcomes, issues, adjustments]
+
+[Copy template for additional phases]
+
+---
+
+## Issues Log
+
+Track issues here as you encounter them. Don't fix during build - log and continue.
+
+| Phase | Issue | Severity | Attempted | Status |
+|-------|-------|----------|-----------|--------|
+| 1 | [description] | Low/Med/High | [what was tried] | Open/Resolved |
+| 2 | [description] | Low/Med/High | [what was tried] | Open/Resolved |
+
+**Severity Guide:**
+- **High:** Blocks future phases, must fix before continuing
+- **Med:** Affects functionality but can work around
+- **Low:** Cosmetic, edge case, or false positive
+
+**End of Build:** Review this log. Tackle High→Med→Low. Some Low issues may not need fixing.
+
+---
+
+## Master Plan Notes
+
+**Cross-Phase Patterns:**
+[Patterns discovered that span multiple phases]
+
+**Blockers & Resolutions:**
+[Significant blockers and how resolved]
+
+**Adjustments:**
+[Changes to planned phases - scope changes, phases added/merged]
+
+---
+
+## Final Completion Checklist
+
+### Before Closing Master Plan
+
+- [ ] All phases complete
+- [ ] All sub-plans closed
+- [ ] Issues Log reviewed - High/Med issues addressed
+- [ ] Full branch audit: `drone @seedgo audit @branch`
+- [ ] Branch memories updated:
+  - [ ] `BRANCH.local.json` - full session log
+  - [ ] `BRANCH.observations.json` - patterns learned
+- [ ] README.md updated (status, architecture, API - if build changed capabilities)
+- [ ] Artifacts reviewed (devpulse manages cleanup)
+- [ ] Final email to @devpulse:
+  ```bash
+  drone @ai_mail send @devpulse "FPLAN-0010 MASTER COMPLETE" "Full build summary: phases completed, deliverables, remaining issues (if any)"
+  ```
+
+**Completion Order:** Memories → README → Email (README before email - don't report complete with stale docs)
+
+**Note:** Devpulse will perform its own Seedgo audit for visibility into the work.
+
+### Definition of Done
+[What specifically defines the project complete?]
+
+---
+
+## Close Command
+
+When ALL phases complete and checklist done:
+```bash
+drone @flow close FPLAN-0010
+```
@@ -1,14 +0,0 @@
-# MEMORY Branch-Local Context
-<!-- Source: /home/patrick/Projects/AIPass/src/aipass/memory/.aipass/branch_system_prompt.md -->
-
-> Auto-created by aipass init. Customize for your branch.
-
-## Status: NEEDS CONFIGURATION
-
-This file is injected into every AI conversation when working from this branch directory. Configure it with:
-
- Who this branch is (role, purpose)
- Key commands and workflows
- Architecture overview
- Critical files and operational rules
- Integration points with other branches
@@ -36,7 +36,7 @@ from typing import Dict, Any, List
 logger = logging.getLogger(__name__)

 # Paths resolved relative to handler location
-_MEMORY_ROOT = Path(__file__).resolve().parents[4]
+_MEMORY_ROOT = Path(__file__).resolve().parents[3]
 CODE_ARCHIVE_PATH = _MEMORY_ROOT / "code_archive"
 INDEX_PATH = CODE_ARCHIVE_PATH / "index.json"

@@ -45,7 +45,7 @@ from datetime import datetime
 logger = logging.getLogger(__name__)

 # Resolve paths relative to handler location
-_MEMORY_ROOT = Path(__file__).resolve().parents[4]
+_MEMORY_ROOT = Path(__file__).resolve().parents[3]
 _CONFIG_DIR = _MEMORY_ROOT / "config"
 _TEMPLATES_DIR = _MEMORY_ROOT / "apps" / "json_templates"

@@ -52,7 +52,7 @@ from aipass.memory.apps.handlers.json.json_handler import (
 )

 # ChromaDB subprocess for vectorization (resolved relative to handler location)
-_MEMORY_ROOT = Path(__file__).resolve().parents[4]
+_MEMORY_ROOT = Path(__file__).resolve().parents[3]
 CHROMA_SUBPROCESS_SCRIPT = _MEMORY_ROOT / "apps" / "handlers" / "storage" / "chroma_subprocess.py"

 # Defaults
@@ -117,7 +117,7 @@ def _load_config() -> Dict[str, Any]:
        Config dict, or empty dict on error
    """
    # Look for config relative to this handler's location
-    config_path = Path(__file__).resolve().parents[4] / "config" / "memory_bank.config.json"
+    config_path = Path(__file__).resolve().parents[3] / "config" / "memory_bank.config.json"

    if not config_path.exists():
        return {}
@@ -54,7 +54,7 @@ from aipass.memory.apps.handlers.monitor.detector import check_single_file
 logger = logging.getLogger(__name__)

 # Memory root resolved relative to handler location
-_MEMORY_ROOT = Path(__file__).resolve().parents[4]
+_MEMORY_ROOT = Path(__file__).resolve().parents[3]

 # Global observer instance
 _observer: Optional[Observer] = None
@@ -47,7 +47,7 @@ from pathlib import Path
 logger = logging.getLogger(__name__)

 # Resolve paths relative to handler location
-_MEMORY_ROOT = Path(__file__).resolve().parents[4]
+_MEMORY_ROOT = Path(__file__).resolve().parents[3]

 # Shared ChromaDB client (reuse from chroma handler)
 from aipass.memory.apps.handlers.storage.chroma import get_client
@@ -47,7 +47,7 @@ from datetime import datetime
 logger = logging.getLogger(__name__)

 # Resolve paths relative to handler location
-_MEMORY_ROOT = Path(__file__).resolve().parents[4]
+_MEMORY_ROOT = Path(__file__).resolve().parents[3]

 # ChromaDB client - create inline since the old symbolic.chroma_client
 # was an internal singleton wrapper
@@ -6,7 +6,7 @@ Checks 3-layer pattern, handler independence, file size, domain organization.
 For entry points, also verifies entire branch structure against template baseline.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: architecture_check.py
 # Description: Architecture Standards Checker Handler
 # Version: 1.0.0
@@ -5,7 +5,7 @@ Provides formatted Architecture standards content.
 Module orchestrates, handler implements.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: architecture_content.py
 # Description: Architecture Standards Content Handler
 # Version: 1.0.0
@@ -5,7 +5,7 @@ Validates module compliance with AIPass CLI standards.
 Checks console.print() usage, CLI service imports, handler separation.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: cli_check.py
 # Description: CLI Standards Checker Handler
 # Version: 1.0.0
@@ -233,9 +233,10 @@ def check_handler_separation(content: str) -> Dict:
            console_print_lines.append(i)

        # Look for actual CLI service imports
-        if 'from cli.apps.modules import' in stripped:
+        if 'from aipass.cli.apps.modules import' in stripped or 'from aipass.cli import' in stripped:
            # Skip if in a string
-            if '"from cli.apps.modules import' in line or "'from cli.apps.modules import" in line:
+            if ('"from aipass.cli.apps.modules import' in line or "'from aipass.cli.apps.modules import" in line
+                    or '"from aipass.cli import' in line or "'from aipass.cli import" in line):
                continue
            # This is likely an actual import
            cli_import_lines.append(i)
@@ -288,12 +289,12 @@ def check_cli_imports(content: str, module_path: str = "") -> Optional[Dict]:
            'message': 'CLI branch exempt (uses internal imports)'
        }

-    # Check for CLI imports
-    has_cli_imports = 'from cli.apps.modules import' in content
+    # Check for CLI imports (canonical or shortcut via cli/__init__.py)
+    has_cli_imports = 'from aipass.cli.apps.modules import' in content or 'from aipass.cli import' in content

    if has_cli_imports:
-        # Check what's imported
-        import_match = re.search(r'from cli\.apps\.modules import (.+)', content)
+        # Check what's imported (canonical full path or shortcut via __init__.py)
+        import_match = re.search(r'from aipass\.cli\.apps\.modules import (.+)', content) or re.search(r'from aipass\.cli import (.+)', content)
        if import_match:
            imports = import_match.group(1)
            return {
@@ -5,7 +5,7 @@ Provides formatted CLI standards content.
 Module orchestrates, handler implements.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: cli_content.py
 # Description: CLI Standards Content Handler
 # Version: 1.0.0
@@ -13,7 +13,7 @@ apps/handlers/ or apps/modules/). Non-entry-point files are skipped
 with a pass.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: cli_flags_check.py
 # Description: CLI Flags Standards Checker Handler
 # Version: 1.0.0
@@ -4,7 +4,7 @@ CLI Flags Standards Content
 Provides Rich-formatted reference text for the CLI flags standard.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: cli_flags_content.py
 # Description: CLI Flags Standards Content
 # Version: 1.0.0
@@ -5,7 +5,7 @@ Uses pyright to detect type errors, undefined variables, and other
 static analysis issues that would show as Pylance errors in VS Code.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: diagnostics_check.py
 # Description: Type Error Diagnostics Checker
 # Version: 1.0.0
@@ -5,7 +5,7 @@ Validates documentation compliance: module docstrings and function docstrings.
 META block validation is handled separately by meta_check.py.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: documentation_check.py
 # Description: Documentation Standards Checker Handler
 # Version: 1.0.0
@@ -5,7 +5,7 @@ Condensed documentation standards verified against actual codebase.
 Truth-checked 2025-11-13 against spawn and seedgo production code.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: documentation_content.py
 # Description: Documentation Standards Content Handler
 # Version: 1.0.0
@@ -28,9 +28,9 @@ def get_documentation_standards() -> str:
        "",
        "─" * 70,
        "",
-        "[bold cyan]REQUIRED: META HEADER (Every Python file)[/bold cyan]",
+        "[bold cyan]REQUIRED: AIPass HEADER (Every Python file)[/bold cyan]",
        "",
-        "  [dim]# =================== META ====================[/dim]",
+        "  [dim]# =================== AIPass ====================[/dim]",
        "  [dim]# Name: filename.py[/dim]",
        "  [dim]# Description: Brief description of the file[/dim]",
        "  [dim]# Version: 1.0.0[/dim]",
@@ -39,7 +39,7 @@ def get_documentation_standards() -> str:
        "  [dim]# =============================================[/dim]",
        "",
        "[yellow]KEY RULES:[/yellow]",
-        "  1. META block = AI-scannable metadata",
+        "  1. AIPass block = AI-scannable metadata",
        "  2. Name must match the actual filename",
        "  3. Version uses semantic versioning (X.Y.Z)",
        "  4. Created/Modified use ISO date format (YYYY-MM-DD)",
@@ -58,7 +58,7 @@ def get_documentation_standards() -> str:
        "  \"\"\"[/dim]",
        "",
        "[yellow]RULES:[/yellow]",
-        "  • Goes right after META block",
+        "  • Goes right after AIPass block",
        "  • Tells WHAT the file does (not HOW)",
        "  • Keep brief - details go in function docstrings",
        "",
@@ -7,7 +7,7 @@ Validates that handlers are properly encapsulated:
 - Handlers should be accessed through module entry points, not directly
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: encapsulation_check.py
 # Description: Handler Encapsulation Standards Checker
 # Version: 1.0.0
@@ -426,9 +426,14 @@ def check_cross_package_imports(lines: List[str], module_path: str,
            continue

        # Allow default handlers
+        is_allowed = False
        for allowed in allowed_handlers:
            if allowed in code_part:
-                continue
+                is_allowed = True
+                break
+
+        if is_allowed:
+            continue

        # This is a cross-package handler import
        violations.append({
@@ -5,7 +5,7 @@ Validates module compliance with AIPass 3-tier logging standards.
 Checks Prax imports in modules/handlers, logger calls in handlers.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: error_handling_check.py
 # Description: Error Handling Standards Checker Handler
 # Version: 1.0.0
@@ -163,6 +163,7 @@ def check_module_has_prax(content: str, file_path: str, bypass_rules: list | Non
    has_prax_import = (
        'from aipass.prax import logger' in content
        or 'from aipass.prax import' in content and 'logger' in content
+        or 'from aipass.prax.apps.modules.logger import system_logger' in content
    )

    if has_prax_import:
@@ -238,7 +239,7 @@ def check_module_error_logging(content: str) -> Dict:
    """
    has_prax_import = 'from aipass.prax import logger' in content or (
        'from aipass.prax import' in content and 'logger' in content
-    )
+    ) or 'from aipass.prax.apps.modules.logger import system_logger' in content

    if has_prax_import:
        return {
@@ -5,7 +5,7 @@ Provides formatted error handling standards content (3-tier architecture).
 Module orchestrates, handler implements.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: error_handling_content.py
 # Description: Error Handling Standards Content Handler
 # Version: 1.0.0
@@ -5,7 +5,7 @@ Validates handler compliance with AIPass handler standards.
 Checks handler independence, auto-detection pattern, no orchestration.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: handlers_check.py
 # Description: Handlers Standards Checker Handler
 # Version: 1.0.0
@@ -8,7 +8,7 @@ Provides formatted handlers standards content.
 Module orchestrates, handler implements.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: handlers_content.py
 # Description: Handlers Content
 # Version: 1.0.0
@@ -6,7 +6,7 @@ Checks for clean pip-style imports: no AIPASS_ROOT, no sys.path hacking,
 proper aipass.* namespace usage, correct import order.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: imports_check.py
 # Description: Imports Standards Checker Handler
 # Version: 2.0.0
@@ -5,7 +5,7 @@ Provides formatted import standards content.
 Module orchestrates, handler implements.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: imports_content.py
 # Description: Import Standards Content Handler
 # Version: 1.0.0
@@ -7,7 +7,7 @@ Validates JSON handling patterns for pip packages:
 - Branch detection via AIPASS_REGISTRY.json and BRANCH_REGISTRY.json
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: json_structure_check.py
 # Description: JSON Structure Standards Checker Handler
 # Version: 2.0.0
@@ -5,7 +5,7 @@ Provides formatted JSON structure standards content.
 Module orchestrates, handler implements.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: json_structure_content.py
 # Description: JSON Structure Standards Content Handler
 # Version: 1.0.0
@@ -12,7 +12,7 @@ THE STANDARD:
 - Prax's own logging infrastructure is exempt (it IS the implementation)
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: log_handler_check.py
 # Description: Log Handler Standards Checker Handler
 # Version: 1.0.0
@@ -4,7 +4,7 @@ Log Handler Standards Content
 Provides Rich-formatted reference text for the log handler rotation standard.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: log_handler_content.py
 # Description: Log Handler Standards Content
 # Version: 1.0.0
@@ -12,7 +12,7 @@ THE STANDARD:
 - INFO = Normal operations, successful completions, discoveries
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: log_level_check.py
 # Description: Log Level Hygiene Standards Checker Handler
 # Version: 1.0.0
@@ -4,7 +4,7 @@ Log Level Hygiene Standards Content
 Provides Rich-formatted reference text for the log level hygiene standard.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: log_level_content.py
 # Description: Log Level Hygiene Standards Content
 # Version: 1.0.0
@@ -6,7 +6,7 @@ every module should have a logs/ directory for module-local logs.
 No hardcoded absolute log paths.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: log_structure_check.py
 # Description: Log Structure Standards Checker Handler
 # Version: 1.0.0
@@ -4,7 +4,7 @@ Log Structure Standards Content Handler
 Provides formatted display of log structure standards for terminal output.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: log_structure_content.py
 # Description: Log Structure Standards Content Handler
 # Version: 1.0.0
@@ -12,7 +12,7 @@ TWO CHECKS:
 Prax logging infrastructure and test files are exempt from both checks.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: log_visibility_check.py
 # Description: Log Visibility Standards Checker Handler
 # Version: 1.0.0
@@ -4,7 +4,7 @@ Log Visibility Standards Content
 Provides Rich-formatted reference text for the log visibility standard.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: log_visibility_content.py
 # Description: Log Visibility Standards Content
 # Version: 1.0.0
@@ -6,7 +6,7 @@ Library META is lighter than full META - focuses on identity
 and traceability without branch-specific fields.

 Required META format:
-    # =================== META ====================
+    # =================== AIPass ====================
    # Name: filename.py
    # Description: Brief description of the file
    # Version: X.Y.Z
@@ -15,7 +15,7 @@ Required META format:
    # =============================================
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: meta_check.py
 # Description: META Block Standards Checker Handler
 # Version: 1.0.0
@@ -29,7 +29,9 @@ from typing import Dict, List


 # Header/footer markers for library META
-META_HEADER = "# =================== META ===================="
+# Accept both AIPass (canonical) and META (legacy) header markers
+META_HEADER = "# =================== AIPass ===================="
+META_HEADER_LEGACY = "# =================== META ===================="
 META_FOOTER = "# ============================================="

 # Required fields with validation patterns
@@ -132,7 +134,7 @@ def check_module(module_path: str, bypass_rules: list | None = None) -> Dict:

 def check_meta_presence(content: str) -> Dict:
    """Check that META block header and footer markers exist"""
-    has_header = META_HEADER in content
+    has_header = META_HEADER in content or META_HEADER_LEGACY in content
    has_footer = META_FOOTER in content

    if has_header and has_footer:
@@ -5,7 +5,7 @@ Validates module compliance with AIPass module standards.
 Checks handle_command pattern, thin orchestration, file size guidelines.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: modules_check.py
 # Description: Modules Standards Checker Handler
 # Version: 1.0.0
@@ -5,7 +5,7 @@ Provides formatted module standards content.
 Module orchestrates, handler implements.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: modules_content.py
 # Description: Modules Standards Content Handler
 # Version: 1.0.0
@@ -5,7 +5,7 @@ Validates module compliance with AIPass naming standards.
 Checks file naming, function naming, variable naming, constant naming.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: naming_check.py
 # Description: Naming Standards Checker Handler
 # Version: 1.0.0
@@ -5,7 +5,7 @@ Provides formatted naming standards content.
 Module orchestrates, handler implements.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: naming_content.py
 # Description: Naming Standards Content Handler
 # Version: 1.0.0
@@ -13,7 +13,7 @@ THE STANDARD:
 - Documentation files that mention these flags for reference are exempt
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: permission_flags_check.py
 # Description: Permission Flags Standards Checker Handler
 # Version: 1.0.0
@@ -4,7 +4,7 @@ Permission Flags Standards Content
 Provides Rich-formatted reference text for the permission flags standard.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: permission_flags_content.py
 # Description: Permission Flags Standards Content
 # Version: 1.0.0
@@ -12,7 +12,7 @@ Checks:
 6. Command list presence (commands/usage section is not empty)
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: readme_check.py
 # Description: README Standards Checker Handler
 # Version: 1.0.0
@@ -4,7 +4,7 @@ README Standards Content
 Provides Rich-formatted reference text for the README standard.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: readme_content.py
 # Description: README Standards Content
 # Version: 1.0.0
@@ -13,7 +13,7 @@ Sections generated:
 - Last Updated timestamp
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: readme_generator.py
 # Description: README Section Auto-Generator
 # Version: 1.0.0
@@ -6,7 +6,7 @@ generator loading, and target resolution. Returns data structures for the
 module to display.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: readme_ops.py
 # Description: README Update Operations Handler
 # Version: 1.0.0
@@ -7,7 +7,7 @@ pyproject.toml entry points or python3 -m.  Shebangs are unnecessary
 and should be removed.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: shebang_check.py
 # Description: Shebang Standards Checker Handler
 # Version: 1.0.0
@@ -5,7 +5,7 @@ Scans Spawn template directory and generates baseline structure.
 Respects .registry_ignore.json patterns.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: template_scanner.py
 # Description: Template Scanner - Automatically scan template to discover structure
 # Version: 1.0.0
@@ -6,7 +6,7 @@ Checks for test functions, error handling patterns.
 Note: Manual testing is acceptable in current rapid iteration phase.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: testing_check.py
 # Description: Testing Standards Checker Handler
 # Version: 1.0.0
@@ -15,7 +15,7 @@ Valid bypass categories for .seedgo/bypass.json:
 - utility: Helper called by event-firing function
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: trigger_check.py
 # Description: Trigger Standards Checker Handler
 # Version: 1.0.0
@@ -5,7 +5,7 @@ Provides formatted Trigger event bus standards content.
 Module orchestrates, handler implements.
 """

-# =================== META ====================
+# =================== AIPass ====================
 # Name: trigger_content.py
 # Description: Trigger Standards Content Handler
 # Version: 1.0.0
@@ -36,7 +36,7 @@ apps/handlers/ (Implementation Layer)

 **Rule:** All branches must match the Spawn template structure.

-**Source of Truth:** `<project_root>/spawn/templates/agent.template/.template_registry.json`
+**Source of Truth:** `src/aipass/spawn/templates/builder/.template_registry.json`

 **What it checks:**
 - All required files from template exist in branch (with proper name transformations)
@@ -50,7 +50,7 @@ apps/handlers/ (Implementation Layer)
 - `OBSERVATIONS.json` → `{BRANCHNAME}.observations.json`
 - `AI_MAIL.json` → `{BRANCHNAME}.ai_mail.json`
 - `BRANCH.py` → `{branchname}.py` (e.g., `seedgo.py`)
- `README.md` → `README.json` (template uses .md, branches use .json)
+- `README.md` → `README.md` (branches keep their README as markdown)

 **WHY:** Spawn creates branches from template. If branches drift from template structure (missing files/directories), updates break and branch becomes non-standard. Template is the contract - all branches must honor it.

@@ -166,7 +166,7 @@ apps/handlers/
  └── cli/        → Everything about user interaction
 ```

-**Verified from:** `<project_root>/spawn/apps/handlers/` - These are actual domains from Spawn.
+**Verified from:** `src/aipass/spawn/apps/handlers/` - These are actual domains from Spawn.

 **Note:** Actual domain names will vary by branch purpose. See naming.md for domain naming standards.

@@ -311,7 +311,7 @@ Run 'python3 create_plan.py --help' for usage
 - Remove module → automatically gone
 - Zero maintenance overhead

-**Implementation:** See `<project_root>/seedgo/apps/seedgo.py` and `<project_root>/seedgo/apps/modules/architecture_standard.py` for reference pattern.
+**Implementation:** See `src/aipass/seedgo/apps/seedgo.py` and `src/aipass/seedgo/apps/modules/architecture_standard.py` for reference pattern.

 ---

@@ -307,6 +307,8 @@ Current flag support across 10 branch entry points:

 **Summary:** --help is 10/10. Everything else is 0-2/10. Significant opportunity for standardization.

+**Note (2026-03-08):** This survey covers the original 10 branches. Five additional branches — BACKUP, DAEMON, MEMORY, COMMONS, and SKILLS — were added after this survey and are not reflected in the table above. They need the same flag standardization treatment and should be audited during Phase 1 rollout.
+
 ---

 ## Notes
@@ -40,12 +40,12 @@ The diagnostics checker runs pyright on Python files to detect:

 ### Single File
 ```bash
-python3 src/aipass/seedgo/apps/handlers/standards/diagnostics_check.py /path/to/file.py
+python3 src/aipass/seedgo/apps/standards/aipass/handlers/standards/diagnostics_check.py /path/to/file.py
 ```

 ### Entire Directory
 ```bash
-python3 src/aipass/seedgo/apps/handlers/standards/diagnostics_check.py src/aipass/seedgo/apps/
+python3 src/aipass/seedgo/apps/standards/aipass/handlers/standards/diagnostics_check.py src/aipass/seedgo/apps/
 ```

 ### Branch Check
@@ -183,6 +183,6 @@ drone @seedgo audit --diagnostics

 ## Reference

- **Checker:** `src/aipass/seedgo/apps/handlers/standards/diagnostics_check.py`
+- **Checker:** `src/aipass/seedgo/apps/standards/aipass/handlers/standards/diagnostics_check.py`
 - **Pyright Docs:** https://microsoft.github.io/pyright/
 - **Python Typing:** https://docs.python.org/3/library/typing.html
@@ -101,7 +101,7 @@ Trigger is the ONE place where cross-branch handler imports are acceptable:

 ```python
 # In trigger/apps/handlers/events/startup.py
-from aipass.memory_bank.apps.handlers.mbank.rollover import check_and_rollover
+from aipass.memory.apps.handlers.rollover import check_and_rollover
 ```

 **WHY:** Trigger's entire purpose is centralizing cross-branch reaction logic. It's the exception that proves the rule - instead of scattered cross-branch calls, Trigger owns them all in one place.
@@ -154,6 +154,6 @@ For legitimate architectural exceptions, configure `.seedgo/bypass.json`:

 ## Reference

- **Checker:** `src/aipass/seedgo/apps/handlers/standards/encapsulation_check.py`
+- **Checker:** `src/aipass/seedgo/apps/standards/aipass/handlers/standards/encapsulation_check.py`
 - **Handler Standard:** `src/aipass/seedgo/docs/aipass_code_standards/handlers.md`
 - **Architecture Standard:** `src/aipass/seedgo/docs/aipass_code_standards/architecture.md`
@@ -141,7 +141,7 @@ Handler → imports Module ✗ (creates cycle)
 **✅ ALLOWED - Same-branch handler imports (even across packages):**

 ```python
-# seedgo/apps/handlers/standards/imports_check.py
+# seedgo/apps/standards/aipass/handlers/standards/imports_check.py
 from aipass.seedgo.apps.handlers.json import json_handler  # ✅ OK - same branch

 # flow/apps/handlers/plan/create.py
@@ -163,7 +163,7 @@ from .logger import log_operation_start, log_operation_end
 **❌ FORBIDDEN - Handler imports own branch's modules:**

 ```python
-# seedgo/apps/handlers/json/json_handler.py
+# seedgo/apps/standards/aipass/handlers/json/json_handler.py
 from aipass.seedgo.apps.modules.create_thing import something  # ❌ NO - circular risk
 ```

@@ -655,7 +655,7 @@ handlers/
 **Current structure:**

 ```
-<project_root>/seedgo/apps/handlers/
+<project_root>/seedgo/apps/standards/aipass/handlers/
  ├── json/
  │   ├── json_handler.py          → JSON file operations (279 lines)
  │   └── test_auto_detection.py   → Tests
@@ -1,10 +1,9 @@
 # Import Standards
-**Status:** Draft v1
-**Date:** 2025-11-12
+**Status:** Draft v2
+**Date:** 2026-03-08

 ---
-#@comments:patrick:whole file needs updating
-## Standard Import Order 
+## Standard Import Order

 **Every Python file follows this pattern:**

@@ -37,7 +36,7 @@ from aipass.seedgo.apps.handlers.domain1 import ops
 3. **Services** - CLI, other branch services (import before internal handlers)
 4. **Internal imports** - After all external dependencies resolved

-> **Note:** AIPass uses pip-installable namespace imports (`from aipass.{module}...`). No `sys.path` manipulation or `AIPASS_ROOT` path setup is needed.
+> **Note:** AIPass uses pip-installable namespace imports (`from aipass.{module}...`). No `sys.path` manipulation needed.

 ---

@@ -110,14 +109,17 @@ logger.warning("Memory file not found, using defaults")
 logger.error("Failed to backup branch", exc_info=True)
 ```

-**Consistency:** Same import pattern everywhere
+**Both forms are valid:**
 ```python
-# Always this
+# Canonical (full path)
 from aipass.prax.apps.modules.logger import system_logger as logger

-# Never variations like these
-from aipass.prax import logger  # ✗
+# Shorthand (via prax/__init__.py)
+from aipass.prax import logger
+
+# Never these
 import aipass.prax.system_logger  # ✗
+import logging; logging.getLogger()  # ✗ Use prax, not stdlib logging
 ```

 **Output location:** Prax manages log files, branches don't need to worry about where logs go
@@ -206,7 +208,7 @@ Some AIPass services need to know **which branch is calling them** to provide pr
 - **Prax** - Logging service
 - **CLI** - Console formatting and output
 - **API** - LLM calls and AI interactions
- **Memory Bank** - Vector storage and search
+- **Memory** - Vector storage and search

 **Router Services (CLI Invocation Only):**
 - **Drone** - NOT a library service, it's a CLI router
@@ -258,7 +260,7 @@ from aipass.drone.apps.modules.router import route_command  # NO!
 ```

 **Why Drone is different:**
- **Prax/CLI/API/Memory Bank**: Library services providing functionality via imports
+- **Prax/CLI/API/Memory**: Library services providing functionality via imports
 - **Drone**: CLI router that resolves targets and invokes other tools
 - Branches receive already-resolved paths/commands from Drone
 - Branches don't need @ handling code - Drone does that BEFORE calling them
@@ -495,7 +497,7 @@ from aipass.seedgo.apps.handlers.json import json_handler

 | Import Type | Pattern | Required? |
 |-------------|---------|-----------|
-| Prax logger | `from aipass.prax.apps.modules.logger import system_logger as logger` | **Nearly always** |
+| Prax logger | `from aipass.prax.apps.modules.logger import system_logger as logger` or `from aipass.prax import logger` | **Nearly always** |
 | CLI service | `from aipass.cli.apps.modules import console, header` | When needed |
 | API service | `from aipass.api.apps.modules import llm_call` | When needed |
 | **Drone** | `subprocess.run(["drone", "cmd", ...])` | **CLI only - NEVER import** |
@@ -511,13 +513,13 @@ from aipass.seedgo.apps.handlers.json import json_handler

 **Namespace pattern:** `from aipass.{module}...` - never bare imports or hardcoded paths

-**Prax logger:** Nearly always imported - system-wide logging service
+**Prax logger:** Nearly always imported - canonical or shorthand form both valid

-**Service imports:** CLI, API, Memory Bank imported as libraries; Drone invoked via CLI only
+**Service imports:** CLI, API, Memory imported as libraries; Drone invoked via CLI only

 **Drone is special:** NOT a library service - it's a CLI router. Never import from aipass.drone.apps.modules

-**Handler independence:** Same-branch handler→handler ✓, Handler→own-branch-module ✗, Cross-branch handler ✗
+**Handler independence:** Same-branch handler→handler ✓, Handler→service (Prax/CLI/API/Memory) ✓, Handler→own-branch-module ✗

 **Third-party libraries:** Pragmatic approach - install what you need as you build

@@ -534,3 +536,4 @@ from aipass.seedgo.apps.handlers.json import json_handler
 #@comments:2025-11-29:claude: Added explicit "Drone: CLI Router Pattern" section with FORBIDDEN import examples
 #@comments:2025-11-29:claude: Clarified that branches should NEVER import from aipass.drone.apps.modules - Drone resolves @ before calling them
 #@comments:2026-03-07:claude: Cleaned Dev-Pass references - updated to AIPass namespace imports, removed sys.path/AIPASS_ROOT patterns, fixed /home/aipass/ paths, seed->seedgo naming
+#@comments:2026-03-08:claude: Resolved patrick's "whole file needs updating" flag - fixed Memory Bank→Memory (3 occurrences), removed stale AIPASS_ROOT reference, corrected handler independence summary to reflect that handlers CAN import cross-branch services, bumped to Draft v2
@@ -67,12 +67,12 @@ Something breaks:

 ```python
 # ❌ WRONG - Points to seedgo
-SEEDGO_ROOT = Path(__file__).parents[4]  # Points to seedgo branch
+SEEDGO_ROOT = Path(__file__).parents[3]  # Points to seedgo branch
 SEEDGO_JSON_DIR = SEEDGO_ROOT / "seedgo_json"
 JSON_TEMPLATES_DIR = SEEDGO_ROOT / "apps" / "json_templates"

 # ✓ CORRECT - Points to YOUR branch
-API_ROOT = Path(__file__).parents[4]  # Points to api branch
+API_ROOT = Path(__file__).parents[3]  # Points to api branch
 API_JSON_DIR = API_ROOT / "api_json"
 JSON_TEMPLATES_DIR = API_ROOT / "apps" / "json_templates"
 ```
@@ -90,14 +90,14 @@ AIPass uses relative path resolution, not hardcoded paths.
 API_ROOT = Path("/home/user/workspace/AIPass/src/aipass/api")

 # ✓ CORRECT - Relative path resolution
-API_ROOT = Path(__file__).parents[4]  # Adjust N based on handler depth
+API_ROOT = Path(__file__).parents[3]  # Adjust N based on handler depth
 ```

 **Branch path patterns:**
 ```python
 # All branches live under src/aipass/{branch}/
 # Use Path(__file__).parents[N] to navigate up from handler location
-{BRANCH}_ROOT = Path(__file__).parents[4]  # from apps/handlers/json/json_handler.py
+{BRANCH}_ROOT = Path(__file__).parents[3]  # from apps/handlers/json/json_handler.py
 ```

 **2. Update JSON_DIR constant:**
@@ -122,7 +122,7 @@ mkdir -p src/aipass/{branch}/apps/json_templates/default

 **5. Copy templates from seedgo:**
 ```bash
-cp src/aipass/seedgo/apps/json_templates/default/*.json \
+cp src/aipass/seedgo/apps/standards/aipass/json_templates/default/*.json \
   src/aipass/{branch}/apps/json_templates/default/
 ```

@@ -145,7 +145,7 @@ drone @seedgo audit {branch}
 1. **Using hardcoded paths instead of `Path(__file__).parents[N]`** ← Most common error!
   - Always use relative path resolution from the handler file
   - `BRANCH_ROOT = Path("/absolute/path/to/branch")` → FAILS
-   - `BRANCH_ROOT = Path(__file__).parents[4]` → PASSES
+   - `BRANCH_ROOT = Path(__file__).parents[3]` → PASSES

 2. **Copying seedgo's handler without changing paths**
   - API and Drone both made this mistake
@@ -353,27 +353,26 @@ json_handler.log_operation("operation_name", {"key": "value"})
 {
  "metadata": {
    "version": "1.0.0",
-    "last_updated": "2025-11-13",
-    "total_branches": 17
+    "last_updated": "2026-03-08",
+    "total_branches": 15
  },
-  "branches": [
-    {
-      "name": "FLOW",
+  "branches": {
+    "flow": {
+      "name": "flow",
      "path": "src/aipass/flow",
      "email": "@flow",
-      "status": "active",
-      "created": "2025-10-30"
+      "status": "active"
    },
-    {
-      "name": "SEEDGO",
+    "seedgo": {
+      "name": "seedgo",
      "path": "src/aipass/seedgo",
      "email": "@seedgo",
-      "status": "active",
-      "created": "2025-10-30"
+      "status": "active"
    }
-  ]
+  }
 }
 ```
+**Note:** `total_branches` is auto-computed by `setup.sh` — do not hardcode it manually. The count shown above is representative; the actual value reflects whatever branches are registered at build time.

 **Registry characteristics:**
 - **Central source of truth** for collections
@@ -644,7 +643,7 @@ ls /branch/branch_json/

 ### Reference Implementation

-**Primary handler:** `src/aipass/seedgo/apps/handlers/json/json_handler.py`
+**Primary handler:** `src/aipass/seedgo/apps/standards/aipass/handlers/json/json_handler.py`

 **Branch implementations:**
 - `src/aipass/drone/apps/handlers/json/json_handler.py`
@@ -65,11 +65,11 @@ On 2026-02-26, the entire AIPass command infrastructure crashed because telegram
 - **Python recursion limit hit** at 1000 levels deep, cascading `RecursionError`
 - **Every `drone` command failed** — 30+ second hangs then crash

-All other branches using prax's `system_logger` rotated correctly (verified: `.log.1` backups exist). The telegram bots were the only code bypassing prax.
+All other branches using prax's `system_logger` rotated correctly (verified: `.log.1` backups exist). The telegram bots were the only code bypassing prax. (Telegram integration has since been removed from AIPass.)

 ## Checker

-**File:** `src/aipass/seedgo/apps/handlers/standards/log_handler_check.py`
+**File:** `src/aipass/seedgo/apps/standards/aipass/handlers/standards/log_handler_check.py`

 Checks:
 1. No raw `logging.FileHandler()` usage
@@ -1,274 +1,177 @@
 # Naming Conventions
-**Status:** Draft v2 (Truth-checked against codebase)
-**Date:** 2025-11-13
+**Status:** Active v3
+**Date:** 2026-03-08

 ---

 ## Core Principle: Path = Context, Name = Action

-**Bad:** `cortex/apps/handlers/branch/cortex_branch_file_ops.py`
-**Good:** `cortex/apps/handlers/branch/file_ops.py`
+The path tells you where you are. The filename tells you what the file does. Don't repeat the path in the name.

-**WHY:** The path already tells you it's Cortex → apps → handlers → branch operations. Adding "cortex_branch_" repeats information you already have.
+**Bad:** `spawn/apps/handlers/json/spawn_json_ops.py`
+**Good:** `spawn/apps/handlers/json/json_handler.py`

-**Result:** Clean, scannable names. No lies when code moves. Easier imports.
+The path already says it's Spawn's JSON handler directory. The filename says what it does.

-**REALITY CHECK:** This principle is aspirational. Current codebase has violations (e.g., `json_ops.py`, `json_handler.py` in json/ directory). New code should follow the principle; legacy code being migrated gradually.
+**Why this matters:**
+- Clean, scannable names
+- No lies when code moves between directories
+- Shorter imports: `from aipass.spawn.apps.handlers.json.json_handler import JsonHandler`

 ---

-## What Problems Does Consistent Naming Solve?
+## Entry Points

-### 1. The Navigation Problem
+Every branch has a single entry point at `apps/{branch_name}.py`. This is the only rigid naming rule for entry points.

-Without consistency, finding functionality becomes search:
- "Where is JSON handler? Maybe `json_ops.py`? Or `cortex_json.py`? Or `json_operations.py`?"
- Every branch uses different names
- Agents and humans waste time exploring instead of executing
-
-**Solution:** Standardized locations = predictable navigation
- Need JSON operations? Always `handlers/json/ops.py`
- Need error decorators? Always `handlers/error/decorators.py`
- No guessing. Direct access.
-
-### 2. The Comparison Problem
-
-**Without consistency:**
-```bash
-# Can't compare - different names, different locations
-cortex/cortex_json_handler.py
-flow/json_operations.py
-prax/handlers/json_ops.py
+```
+cli/apps/cli.py
+drone/apps/drone.py
+flow/apps/flow.py
+spawn/apps/spawn.py
+prax/apps/prax.py
+seedgo/apps/seedgo.py
+trigger/apps/trigger.py
+memory/apps/memory.py
+daemon/apps/daemon.py
+api/apps/api.py
+ai_mail/apps/ai_mail.py
+backup/apps/backup.py
 ```

-**With consistency:**
-```bash
-# Easy comparison - same name, same location
-cat cortex/apps/handlers/json/ops.py
-cat flow/apps/handlers/json/ops.py
-cat prax/apps/handlers/json/ops.py
+Never name an entry point `main.py`. The branch name is the entry point name.
+
+---
+
+## Module Files
+
+Module files live under `apps/modules/` and are named for what they do. There is no rigid naming convention beyond clarity. Names are decided during planning based on the module's purpose.
+
+**Real examples:**
+```
+spawn/apps/modules/core.py              # Core spawn logic
+spawn/apps/modules/passport.py          # Passport operations
+spawn/apps/modules/sync_templates.py    # Template syncing
+flow/apps/modules/create_plan.py        # Plan creation
+flow/apps/modules/close_plan.py         # Plan closing
+drone/apps/modules/router.py            # Command routing
+drone/apps/modules/registry.py          # Module registry
+memory/apps/modules/rollover.py         # Memory rollover
+trigger/apps/modules/medic.py           # Self-healing logic
+api/apps/modules/openrouter_client.py   # OpenRouter API client
 ```

-**WHY this matters:** Comparison reveals what's common vs branch-specific. You can't standardize what you can't compare.
+---

-### 3. The Marketplace Problem
+## Handler Files
+
+### The Standard: `handlers/<domain>/<action>.py`
+
+Handlers are the implementation layer. They live under domain-specific subdirectories.
+
+### `json_handler.py` -- The Canonical JSON Handler
+
+Every branch has `handlers/json/json_handler.py`. This is the standard name, not an exception. It exists in 11+ branches with a consistent API.

-**Without consistency:**
 ```
-Branch A needs: json operations
-Marketplace has: 7 different JSON handlers, different APIs
-Result: Integration nightmare, manual adaptation
+cli/apps/handlers/json/json_handler.py
+prax/apps/handlers/json/json_handler.py
+flow/apps/handlers/json/json_handler.py
+spawn/apps/handlers/json/json_handler.py
+trigger/apps/handlers/json/json_handler.py
+memory/apps/handlers/json/json_handler.py
+daemon/apps/handlers/json/json_handler.py
+backup/apps/handlers/json/json_handler.py
+api/apps/handlers/json/json_handler.py
+ai_mail/apps/handlers/json/json_handler.py
+seedgo/apps/standards/aipass/handlers/json/json_handler.py
 ```

-**With consistency:**
+When a branch needs JSON operations, create `handlers/json/json_handler.py`. Some branches also have supplementary files in the same directory (e.g., `load.py`, `save.py`, `initialize.py` in prax) for more granular operations.
+
+### Other Handler Examples
+
+**prax -- monitoring domain:**
 ```
-Branch A needs: handlers/json/ops.py
-Marketplace has: handlers/json/ops.py v1.2
-Result: Drop in, works immediately
+prax/apps/handlers/monitoring/
+    branch_detector.py
+    log_watcher.py
+    module_tracker.py
+    event_queue.py
+    unified_stream.py
+    telegram_relay.py
+```
+
+**prax -- registry domain:**
+```
+prax/apps/handlers/registry/
+    reader.py
+    load.py
+    save.py
+    statistics.py
+    meta_ops.py
+```
+
+**trigger -- events domain:**
+```
+trigger/apps/handlers/events/
+    error_logged.py
+    warning_logged.py
+    memory_threshold_exceeded.py
+    bulletin_created.py
+    startup.py
+```
+
+**memory -- specialized domains:**
+```
+memory/apps/handlers/vector/embedder.py
+memory/apps/handlers/rollover/extractor.py
+memory/apps/handlers/tracking/line_counter.py
+memory/apps/handlers/central_writer.py
 ```

 ---

 ## Why No Redundant Prefixes?

-### The Redundancy Cascade
+`spawn/apps/handlers/json/spawn_json_ops.py`

-`cortex/apps/handlers/json/cortex_json_ops.py`
+What breaks:
+1. **Import bloat:** `from aipass.spawn.apps.handlers.json.spawn_json_ops import SpawnJsonOps`
+2. **Name lies when code moves:** Rename the directory, the prefix is now wrong
+3. **Search noise:** Grep for "spawn" returns every file in the branch
+4. **Visual clutter:** Can't quickly scan a directory listing

-**What breaks:**
-1. **Length explosion:** 50+ character filenames
-2. **Import ugliness:** `from cortex.apps.handlers.json.cortex_json_ops import CortexJsonOps`
-3. **Refactoring nightmare:** Move to different directory? Prefix now lies
-4. **Search pollution:** Grep for "cortex" returns every file
-5. **Visual scanning:** Can't quickly scan directory listings
-
-**Principle:** Information should exist in exactly ONE place. Path tells you context, filename tells you action.
+Information should exist in one place. The path carries context; the filename carries action.

 ---

-## Standard Verbs: The Shared Language
+## Common Naming Patterns

-Same operation should have same name everywhere:
+These are patterns observed across the codebase. They are not prescriptive rules -- use whatever name best describes what the file does. But if your file does one of these things, these names are worth considering since other agents will recognize them:

-**Core operations (verified in codebase):**
- `create` - Create new resource (e.g., `create_thing.py`)
- `ops` - General operations (e.g., `ops.py` in domain handlers)
- `load` - Load configuration/data (e.g., `load_config.py`)
- `save` - Save data (e.g., `save.py` in json handlers)
- `initialize` - Setup/initialization (e.g., `initialize.py`)
-
-**Transformation/Formatting:**
- `formatters` - Transform/format data (e.g., `formatters.py` in error)
- `decorators` - Function decorators (e.g., `decorators.py` in error)
- `logger` - Logging operations (e.g., `logger.py`)
-
-**Handler patterns:**
- `prompts` - User interaction handlers (e.g., `prompts.py` in cli)
- `content` - Content providers (e.g., `cli_content.py`, `naming_content.py`)
-
-**WHY standardize verbs:**
- Grep works: Search for "load" finds all loading operations
- Mental model: See `load_config.py` → instantly know what it does
- API consistency: All "load" operations follow similar patterns
- Cross-branch comparison: Same name = same purpose across all branches
-
---
-
-## Examples: Good vs Bad
-
-**Good (from real codebase):**
-```
-cli/apps/handlers/error/decorators.py     # Path: error domain, name: what it does
-cli/apps/handlers/error/formatters.py     # Path: error domain, name: what it does
-prax/apps/handlers/config/load_config.py  # Path: config domain, name: action
-seedgo/apps/handlers/domain1/ops.py        # Path: domain1, name: operations
-```
-
-**Bad (real violations):**
-```
-prax/apps/handlers/json/json_ops.py       # Redundant "json_" prefix
-modules/plan_manager_module.py            # Redundant "module" suffix (hypothetical)
-```
-
-**Note:** `json_handler.py` is documented as a standardized exception (see Handler Naming Exceptions section below).
-
---
-
-## Handler Naming by Domain
-
-**Pattern:** `handlers/<domain>/<action>.py`
-
-**Real Examples from aipass_core/cli:**
-```
-cli/apps/handlers/
-└── error/
-    ├── decorators.py    # Error handling decorators
-    ├── formatters.py    # Error message formatting
-    ├── logger.py        # Error logging
-    └── result_types.py  # Result type definitions
-```
-
-**Real Examples from aipass_core/prax:**
-```
-prax/apps/handlers/
-├── config/
-│   ├── load_config.py           # Config loading
-│   └── load_ignore_patterns.py  # Ignore pattern loading
-├── json/
-│   ├── initialize.py   # JSON initialization
-│   ├── load.py         # JSON loading
-│   ├── save.py         # JSON saving
-│   └── log.py          # JSON logging
-└── cli/
-    └── prompts.py      # CLI prompt handlers
-```
-
-**Real Examples from seedgo:**
-```
-seedgo/apps/handlers/
-├── domain1/
-│   └── ops.py          # Domain operations (showroom)
-├── standards/
-│   ├── cli_content.py  # CLI standards content
-│   └── naming_content.py # Naming standards content
-└── json/
-    └── json_handler.py  # JSON operations (standardized exception)
-```
-
---
-
-## Handler Naming Exceptions
-
-### `json_handler.py` - Standardized Exception
-
-`json_handler.py` is a documented exception to the "no redundant prefixes" rule. This file exists across 8+ branches with an identical or near-identical API, making it a de facto standard in the ecosystem. Renaming it to `ops.py`, `handler.py`, or other variants would break established patterns and consumer code depending on this specific name. The redundant prefix is intentional here: it serves as a standardized identifier that marks this as THE canonical JSON handler implementation across the AIPass ecosystem. This exception demonstrates that standardization sometimes requires preserving a slightly non-ideal name rather than breaking existing integrations.
-
---
-
-## Why This Enables Speed at Scale
-
-### Zero-Cost Navigation
-**Agent workflow:**
-```
-Task: Update JSON operations in Flow
-Path: flow/apps/handlers/json/ops.py
-Status: FOUND (0 searches required)
-```
-
-**Without consistency:**
-```
-Task: Update JSON operations in Flow
-Attempt 1: Search for "json"... 47 results
-Attempt 2: Search in handlers/... 12 files
-Attempt 3: Read each to find right one
-Status: FOUND (3 searches, 5 file reads)
-```
-
-**Scale impact:** 20 branches × 50 operations = 1000 handlers
- Consistent: Direct navigation to any handler
- Inconsistent: Search required for every access
-
-### Pattern Emergence
-
-Standardization happens naturally when files align:
-
-1. Each branch implements `handlers/json/ops.py` for their needs
-2. Compare all `handlers/json/ops.py` files → common patterns visible
-3. Extract common patterns → create standard handler v1.0
-4. Freeze and reuse → no reinvention needed
-
-**Critical:** This ONLY works with consistent naming. Different names = patterns invisible.
-
-### Learning Transfer
-
-**With consistency:**
-```
-Day 1: Learn Cortex structure
-Day 2: Work on Flow (same structure, instant productivity)
-Day 3: Work on PRAX (same structure, instant productivity)
-```
-
-**Without consistency:**
-```
-Day 1: Learn Cortex structure
-Day 2: Learn Flow structure (different pattern, slower)
-Day 3: Learn PRAX structure (another pattern, still slower)
-```
-
---
-
-## What Breaks with Inconsistent Naming?
-
-1. **Agent assumptions fail** - AI builds mental model ("JSON is always in handlers/json/ops.py") → one branch violates → agent fails
-2. **Comparison tools break** - `diff cortex/.../ops.py flow/.../ops.py` only works if files align
-3. **Search becomes ambiguous** - Every search requires filtering, every filter requires domain knowledge
-4. **Refactoring becomes expensive** - Move file with prefixed name? Now name lies → rename → update imports → test everything
-5. **Marketplace fragments** - Every variant needs own entry, integration guides, version tracking
-
---
-
-## The Speed Equation
-
-**Without consistency:**
- Navigation = Search (O(n) complexity)
- Comparison = Manual mapping (human labor)
- Learning = Per-branch overhead (20 branches = 20 learning curves)
- Standardization = Nearly impossible (patterns hidden)
-
-**With consistency:**
- Navigation = Direct access (O(1) complexity)
- Comparison = Automated tools (machine labor)
- Learning = One-time investment (20 branches = 1 curve)
- Standardization = Natural emergence (patterns obvious)
+- `delivery` -- delivering messages or payloads
+- `detector` -- detecting conditions or changes
+- `embedder` -- creating vector embeddings
+- `extractor` -- extracting data from sources
+- `indexer` -- indexing or cataloging
+- `manager` -- managing lifecycle of a resource
+- `watcher` -- watching for file or event changes
+- `registry` -- maintaining a registry of items
+- `validator` -- validating data or state
+- `formatter` -- formatting output
+- `cleanup` -- cleanup and maintenance operations
+- `scanner` -- scanning directories or data
+- `dispatcher` -- routing or dispatching work
+- `collector` -- collecting data from multiple sources
+- `client` -- API or service client

 ---

 ## Summary

-1. **Path provides context** - Don't encode directory structure in filenames
-2. **Short names win** - Less typing, easier scanning, cleaner imports
-3. **Comparison enables standardization** - Can't standardize what you can't compare
-4. **Standard verbs = shared language** - Same operation, same name, everywhere
-5. **Consistency compounds** - Benefits multiply across branches and time
-
-**The meta-lesson:** Naming consistency isn't pedantry—it's the prerequisite for emergent standardization at scale.
+1. **Path = Context, Name = Action** -- don't encode directory info in filenames
+2. **Entry point is always `{branch_name}.py`** -- never `main.py`
+3. **`json_handler.py` is the standard** -- every branch uses it at `handlers/json/json_handler.py`
+4. **Module and handler names describe what they do** -- no rigid verb system, just clarity
+5. **Short names win** -- less typing, easier scanning, cleaner imports
@@ -63,7 +63,7 @@ The AIPass standard `--permission-mode bypassPermissions` provides:

 ## Checker

-**File:** `seedgo/apps/handlers/standards/permission_flags_check.py`
+**File:** `src/aipass/seedgo/apps/standards/aipass/handlers/standards/permission_flags_check.py`

 Checks:
 1. No `--dangerously-skip-permissions` usage in code (comments/docstrings excluded)
@@ -97,8 +97,8 @@ Auto-generation handles facts (file lists, timestamps). Humans handle meaning.

 | Tool | Purpose | Location |
 |------|---------|----------|
-| `readme_check.py` | 6 automated checks, score >= 75% to pass | `seedgo/apps/handlers/standards/` |
-| `readme_generator.py` | Auto-populates TREE, MODULES, COMMANDS, HEADER, LAST_UPDATED | `seedgo/apps/handlers/standards/` |
+| `readme_check.py` | 6 automated checks, score >= 75% to pass | `src/aipass/seedgo/apps/standards/aipass/handlers/standards/` |
+| `readme_generator.py` | Auto-populates TREE, MODULES, COMMANDS, HEADER, LAST_UPDATED | `src/aipass/seedgo/apps/standards/aipass/handlers/standards/` |
 | `seedgo readme update @branch` | On-demand regeneration (Phase 4, coming soon) | CLI |

 **Checks performed by `readme_check.py`:**
@@ -10,7 +10,7 @@

 **Current approach:** Manual testing with JSON/log verification works effectively for rapid iteration phase.

-**Future:** pytest framework will be introduced once branches stabilize.
+**Future:** pytest framework expansion once branches stabilize (pytest is already configured and operational in some branches).

 ---

@@ -96,10 +96,9 @@ Process:
 ## Future: pytest Framework

 **Infrastructure in place:**
- `pytest.ini` at root - Configuration for test discovery and markers
- `<project_root>/tests/` - Root test directory with conftest.py
- `<project_root>/tests/` - Core system tests
- Branch-specific test directories (API, Prax, CLI, etc.)
+- `pytest.ini` at repo root - Configuration for test discovery and markers
+- `tests/` - Root test directory with conftest.py
+- Branch-specific test directories at `src/aipass/{branch}/tests/` (API, Prax, CLI, etc.)

 **Already operational in some branches:**
 - API branch: 4 test files (test_api_system.py, test_openrouter_key.py, etc.)
@@ -186,9 +185,9 @@ cat module_name_log.json
 ```bash
 # Prax provides file-based logging, not real-time watching
 # Check system logs directory for detailed output
-ls -la ~/system_logs/
-# Read specific module logs
-cat ~/system_logs/module_name.log
+ls -la system_logs/
+# Read specific module logs (Prax manages this directory location)
+cat system_logs/module_name.log
 ```

 **This infrastructure = verification layer without formal tests**
@@ -241,7 +240,7 @@ cat ~/system_logs/module_name.log
 - [ ] Check data.json - state tracking working?
 - [ ] Check log.json - operations recorded?
 - [ ] Test edge cases (invalid input, missing files, etc.)
- [ ] Check Prax logs in ~/system_logs/ for detailed debugging info
+- [ ] Check Prax logs in system_logs/ for detailed debugging info
 - [ ] Manual feature tests at 90% stage

 ---
@@ -289,19 +288,18 @@ cat ~/system_logs/module_name.log

 **Current implementation:**
 ```
-<project_root>/
-  pytest.ini              # Test configuration
-  tests/                  # Root test directory
-    conftest.py           # Shared fixtures
-  src/aipass/
-    api/tests/            # API tests (4 files operational)
-      test_api_system.py
-      test_openrouter_key.py
-      test_free_models_quick.py
-      test_paid_model.py
-    prax/tests/           # Prax tests
-      test_log_rotation.py
-    cli/tests/            # CLI tests (infrastructure ready)
+pytest.ini                          # Test configuration (repo root)
+tests/                              # Root test directory
+  conftest.py                       # Shared fixtures
+src/aipass/
+  api/tests/                        # API tests (4 files operational)
+    test_api_system.py
+    test_openrouter_key.py
+    test_free_models_quick.py
+    test_paid_model.py
+  prax/tests/                       # Prax tests
+    test_log_rotation.py
+  cli/tests/                        # CLI tests (infrastructure ready)
  seedgo/
    tests/conftest.py
    apps/modules/test_cli_errors.py  # Demo module
@@ -313,7 +311,7 @@ cat ~/system_logs/module_name.log
 pytest

 # Run specific branch tests
-pytest aipass_core/api/tests/
+pytest src/aipass/api/tests/

 # Run with markers
 pytest -m unit
@@ -322,9 +320,9 @@ pytest -m slow
 ```

 **Test demonstration module:**
- `<project_root>/src/aipass/seedgo/apps/modules/test_cli_errors.py` - Shows error handling patterns
+- `src/aipass/seedgo/apps/modules/test_cli_errors.py` - Shows error handling patterns
 - Not a pytest test, but demonstrates testing concepts
- Run directly: `python3 <project_root>/src/aipass/seedgo/apps/modules/test_cli_errors.py`
+- Run directly: `python3 src/aipass/seedgo/apps/modules/test_cli_errors.py`

 ---

@@ -332,7 +330,7 @@ pytest -m slow

 #@comments:2025-11-13:claude: Pytest infrastructure exists and operational in API/Prax branches. Selective testing approach: automate stable components, manual testing for rapid development.

-#@comments:2025-11-13:claude: Prax doesn't have real-time "watcher" command for logs - uses file-based logging in ~/system_logs/. Updated documentation to reflect actual capabilities.
+#@comments:2025-11-13:claude: Prax doesn't have real-time "watcher" command for logs - uses file-based logging in system_logs/ (Prax manages the location). Updated documentation to reflect actual capabilities.

 #@comments:2025-11-13:claude: Error-first debugging approach is critical - maybe this should be emphasized in error_handling.md when we fill that section?

@@ -12,7 +12,7 @@ AIPass uses a centralized event system to replace scattered cross-branch functio
 Before (hardcoded):
    flow/close_plan.py → directly calls → dashboard/update_local()
    flow/close_plan.py → directly calls → mbank/process_closed_plans()
-    prax/logger.py → directly calls → memory_bank/check_and_rollover()
+    prax/logger.py → directly calls → memory/check_and_rollover()

 After (event-driven):
    flow/close_plan.py → trigger.fire('plan_closed') → handlers respond
@@ -103,7 +103,7 @@ def fire_event(name, **data):

 ## Handler Requirements

-Handlers live in `<project_root>/trigger/apps/handlers/events/`
+Handlers live in `src/aipass/trigger/apps/handlers/events/`

 ### Handler Interface
 ```python
@@ -151,7 +151,7 @@ def handle_{event_name}(**kwargs) -> None:

 ### Registering Handlers

-All handlers registered in `trigger/apps/handlers/events/registry.py`:
+All handlers registered in `src/aipass/trigger/apps/handlers/events/registry.py`:

 ```python
 from aipass.trigger.apps.modules.core import trigger
@@ -371,7 +371,7 @@ For Trigger branch itself:

 ## Reference

- **Trigger Core:** `<project_root>/trigger/apps/modules/core.py`
- **Handler Registry:** `<project_root>/trigger/apps/handlers/events/registry.py`
- **Event Handlers:** `<project_root>/trigger/apps/handlers/events/*.py`
- **Standard:** `<project_root>/src/aipass/seedgo/docs/aipass_code_standards/trigger.md`
+- **Trigger Core:** `src/aipass/trigger/apps/modules/core.py`
+- **Handler Registry:** `src/aipass/trigger/apps/handlers/events/registry.py`
+- **Event Handlers:** `src/aipass/trigger/apps/handlers/events/*.py`
+- **Standard:** `src/aipass/seedgo/docs/aipass_code_standards/trigger.md`
@@ -1,45 +0,0 @@
-# Spawn - Agent System Prompt
-
-You are **Spawn**, the agent factory for the AIPass ecosystem.
-
-## Your Identity
- Read: `.trinity/passport.json` for your role and purpose
- Read: `.trinity/local.json` for session history and current tasks
- Read: `.trinity/observations.json` for collaboration patterns
-
-## Your Job
-Create new agent branches from templates, replace placeholders, register in AIPASS_REGISTRY.json.
-
-## AI Mail - How to Check & Reply
-Your inbox is at: `.ai_mail.local/inbox.json` (relative to your branch root)
- To read inbox: read the file `.ai_mail.local/inbox.json`
- To send email: `drone @ai_mail send @target "Subject" "Body"`
- To reply: `drone @ai_mail send @sender "Re: Subject" "Your reply"`
-
-## Key Commands
-```
-drone systems                    # List all registered modules
-drone @seedgo audit aipass       # Run standards audit
-drone @spawn --help              # Your own help
-drone @ai_mail send @target "Subject" "Body"  # Send email
-```
-
-## Environment
- Docker container, code-server at localhost:8080
- Python 3.11, drone and seedgo at /usr/local/bin/
- PATH: /usr/local/bin:/home/coder/.local/bin
- Repo root: /home/coder/workspace/AIPass
- Your location: /home/coder/workspace/AIPass/src/aipass/spawn
-
-## Architecture
- 3-layer: `apps/spawn.py` (entry) + `apps/modules/core.py` (orchestration) + `apps/handlers/` (implementation)
- Template at: `templates/agent.template/`
- Registry: `AIPASS_REGISTRY.json` at repo root
- Logging: `from aipass.prax import logger`
-
-## On Wake
-1. Read your .trinity files for context
-2. Check `.ai_mail.local/inbox.json` for new messages
-3. Process any tasks requested
-4. Reply to sender when done
-5. Update `.trinity/local.json` with session notes
@@ -1,8 +0,0 @@
-{
-  "permissions": {
-    "allow": [],
-    "deny": [],
-    "ask": []
-  },
-  "enabledMcpjsonServers": []
-}
@@ -1,115 +0,0 @@
-{
-  "metadata": {
-    "version": "1.0.0",
-    "created": "2025-11-27T16:44:34.325750",
-    "description": "Standards bypass configuration for this branch"
-  },
-  "bypass": [
-    {
-      "file": "apps/modules/standards_checklist.py",
-      "standard": "architecture",
-      "reason": "Large file justified - orchestrates 12 standards, contains bypass system"
-    },
-    {
-      "file": "apps/modules/standards_checklist.py",
-      "standard": "modules",
-      "reason": "Direct file ops required - reads BRANCH_REGISTRY.json and bypass configs"
-    },
-    {
-      "file": "apps/handlers/verify/orchestrator.py",
-      "standard": "cli",
-      "reason": "Display orchestrator - console.print is its PURPOSE (orchestrates display output)"
-    },
-    {
-      "file": "apps/handlers/audit/display.py",
-      "standard": "cli",
-      "reason": "Display handler - console.print is its PURPOSE (formats audit output)"
-    },
-    {
-      "file": "apps/handlers/diagnostics/discovery.py",
-      "standard": "cli",
-      "reason": "Uses print() for error fallback when logger unavailable"
-    },
-    {
-      "file": "apps/modules/cli_standard.py",
-      "standard": "modules",
-      "reason": "Standards education module - run_demo is part of teaching CLI patterns"
-    },
-    {
-      "file": "apps/modules/standards_checklist.py",
-      "standard": "json_structure",
-      "reason": "Direct JSON for bypass system - not three-JSON pattern use case"
-    },
-    {
-      "file": "apps/handlers/standards/architecture_check.py",
-      "standard": "cli",
-      "reason": "False positive - CLI pattern in docstring documenting allowed imports"
-    },
-    {
-      "file": "apps/handlers/standards/imports_check.py",
-      "standard": "cli",
-      "reason": "False positive - CLI pattern in docstring documenting allowed imports"
-    },
-    {
-      "file": "apps/handlers/standards/modules_content.py",
-      "standard": "cli",
-      "reason": "Content handler - CLI examples in strings are its PURPOSE"
-    },
-    {
-      "file": "apps/handlers/standards/cli_check.py",
-      "standard": "cli",
-      "reason": "False positive - CLI pattern in docstring explaining console.print detection"
-    },
-    {
-      "file": "apps/handlers/standards/cli_content.py",
-      "standard": "cli",
-      "reason": "Content handler - CLI examples in strings are its PURPOSE (teaching proper usage)"
-    },
-    {
-      "file": "apps/handlers/standards/imports_content.py",
-      "standard": "cli",
-      "reason": "Content handler - CLI examples in strings are its PURPOSE (teaching proper usage)"
-    },
-    {
-      "file": "apps/handlers/standards/architecture_check.py",
-      "standard": "encapsulation",
-      "reason": "Imports ignore_handler for template patterns - internal SEED checker infrastructure"
-    },
-    {
-      "file": "apps/handlers/standards/error_handling_check.py",
-      "standard": "error_handling",
-      "reason": "False positive - 'logger.error()' pattern appears in docstring teaching the standard"
-    },
-    {
-      "file": "apps/handlers/verify/checker_sync.py",
-      "standard": "trigger",
-      "reason": "False positive - 'unlink' and 'rename' appear in string list, not actual file operations"
-    }
-  ],
-  "notes": {
-    "usage": "Add entries to 'bypass' list to exclude specific violations",
-    "example": {
-      "file": "apps/modules/logger.py",
-      "standard": "cli",
-      "lines": [146, 177],
-      "pattern": "if __name__ == '__main__'",
-      "category": "internal_ops",
-      "reason": "Circular dependency - logger cannot import CLI"
-    },
-    "fields": {
-      "file": "Relative path from branch root (required)",
-      "standard": "Standard name: cli, imports, naming, etc. (required)",
-      "lines": "Optional - specific line numbers to bypass",
-      "pattern": "Optional - pattern to match (e.g. 'if __name__')",
-      "category": "Optional - bypass category for trigger standard",
-      "reason": "Required - why this bypass exists"
-    },
-    "trigger_categories": {
-      "handler_layer": "Function in handlers/ layer (orchestrator fires instead)",
-      "initialization": "One-time setup/config creation",
-      "internal_ops": "Same-module internal operation",
-      "high_frequency": "Would create event spam",
-      "utility": "Helper called by event-firing function"
-    }
-  }
-}
--- a/Show More
+++ b/Show More