Skip to content

Latest commit

 

History

History
361 lines (284 loc) · 9.83 KB

File metadata and controls

361 lines (284 loc) · 9.83 KB

Restructure Issues - Token Optimization Breakdown Analysis

Overview

This document analyzes the three restructure issues (10, 11, 12) to determine if they should be broken down into smaller sub-issues to optimize token usage in ADW workflows.

Token Usage Considerations

Context Requirements

  • Issue markdown: ~3-5K tokens per issue
  • Code files: Variable (100-2000 tokens per file)
  • ADW overhead: ~10-15K tokens (system, workflow, templates)
  • Agent planning: ~5-10K tokens
  • Implementation context: Files being modified

Target Budget

  • Optimal workflow: 40-60K tokens total
  • Warning threshold: 80K tokens
  • Critical threshold: 100K tokens

Issue 10: Mirror app/ Structure - Analysis

Current Structure

  • Issue size: ~4.5K tokens
  • Phases: 8 phases
  • Tasks: ~30 tasks
  • Files to move: ~30 files
  • Import updates: ~30-50 files

Estimated Token Usage (Monolithic)

Planning Phase:

  • Issue spec: 4.5K
  • Current structure scan: 10-15K (reading existing files)
  • Planning output: 3-5K
  • Subtotal: ~20-25K tokens

Implementation Phase (all at once):

  • Issue context: 4.5K
  • Frontend files (18 files): ~15-20K tokens
  • Backend files (12 files): ~10-15K tokens
  • Test files (10 files): ~8-12K tokens
  • Script files (5 files): ~3-5K tokens
  • Import path updates (scan all Python): ~15-20K tokens
  • Subtotal: ~60-80K tokens

Total Estimated: 80-105K tokens (⚠️ WARNING TO CRITICAL)

Recommended Breakdown

Issue 10a: Move Frontend Application

  • Create app/client/ structure
  • Move all frontend files
  • Update frontend configuration
  • Update frontend startup scripts
  • Validate frontend works standalone
  • Estimated: 35-45K tokens ✅

Issue 10b: Reorganize Backend Structure

  • Create app/server/ structure
  • Move backend files
  • Update backend imports
  • Update backend startup scripts
  • Update backend tests
  • Validate backend works standalone
  • Estimated: 40-50K tokens ✅

Issue 10c: Integration & Cleanup

  • Test frontend + backend integration
  • Update README with new structure
  • Clean up old directories
  • Run full test suite
  • Final validation
  • Estimated: 25-35K tokens ✅

Benefits of Breakdown:

  • Each sub-issue stays well under token budget
  • Easier to validate incrementally
  • Lower risk (can roll back individual pieces)
  • Better caching (less context loaded per workflow)
  • Clearer progress tracking

Issue 11: Consolidate Documentation - Analysis

Current Structure

  • Issue size: ~6K tokens
  • Phases: 8 phases
  • Tasks: ~25 tasks
  • Files to move: ~25 documentation files
  • New files to create: ~10 README/index files

Estimated Token Usage (Monolithic)

Planning Phase:

  • Issue spec: 6K
  • Current doc scan: 8-12K (reading existing docs)
  • Planning output: 3-5K
  • Subtotal: ~17-23K tokens

Implementation Phase:

  • Issue context: 6K
  • Feature docs (3 files): ~8-12K tokens
  • Patch specs (8 files): ~12-16K tokens
  • Issue files (12 files): ~15-20K tokens
  • README creation (10 files): ~10-15K tokens
  • ARCHITECTURE.md creation: ~5-8K tokens
  • Path reference updates: ~5-10K tokens
  • Subtotal: ~65-85K tokens

Total Estimated: 82-108K tokens (⚠️ WARNING TO CRITICAL)

Recommended Breakdown

Issue 11a: Documentation Structure & Indexes

  • Create directory structure
  • Create all README indexes
  • Create ARCHITECTURE.md
  • Update main README documentation section
  • Estimated: 30-40K tokens ✅

Issue 11b: Move Feature Docs & Specs

  • Move feature documentation
  • Move patch specifications
  • Update cross-references
  • Validate documentation links
  • Estimated: 35-45K tokens ✅

Issue 11c: Move Issue Tracking Files

  • Move completed issues
  • Move active issues
  • Move planning documents
  • Update all path references
  • Clean up parent directories
  • Final validation
  • Estimated: 30-40K tokens ✅

Benefits of Breakdown:

  • Logical grouping (structure → content → tracking)
  • Each piece validates independently
  • Documentation can be reviewed incrementally
  • Lower token usage per workflow

Issue 12: Extraction Readiness - Analysis

Current Structure

  • Issue size: ~7K tokens
  • Phases: 7 phases
  • Tasks: ~20 tasks
  • Audits: 4 comprehensive audits
  • New scripts: 4 major scripts

Estimated Token Usage (Monolithic)

Planning Phase:

  • Issue spec: 7K
  • Codebase audit scans: 15-25K (grepping all files)
  • Planning output: 5-8K
  • Subtotal: ~27-40K tokens

Implementation Phase:

  • Issue context: 7K
  • Dependency audits (4 audits): ~20-30K tokens
  • Script creation (4 scripts): ~8-12K tokens
  • Documentation updates: ~10-15K tokens
  • EXTRACTION_GUIDE.md: ~6-8K tokens
  • Validation and testing: ~10-15K tokens
  • Subtotal: ~61-87K tokens

Total Estimated: 88-127K tokens (⚠️ CRITICAL)

Recommended Breakdown

Issue 12a: Dependency Audit & Resolution

  • Audit Python imports
  • Audit file path references
  • Audit configuration files
  • Audit script files
  • Resolve all findings
  • Estimated: 45-55K tokens ✅

Issue 12b: Extraction Tooling

  • Create extraction script
  • Create validation script
  • Update configuration for standalone
  • Test scripts
  • Estimated: 35-45K tokens ✅

Issue 12c: Documentation & Final Validation

  • Create EXTRACTION_GUIDE.md
  • Update README extraction section
  • Update ARCHITECTURE.md
  • Run dry run extraction
  • Final validation suite
  • Estimated: 40-50K tokens ✅

Benefits of Breakdown:

  • Audit phase separate from tooling (different focus)
  • Can fix issues found in audit before creating tools
  • Extraction tooling can reference audit findings
  • Final validation catches everything

Summary Recommendation

Break Down All Three Issues

Original Structure (3 issues):

  • Issue 10: 80-105K tokens ⚠️
  • Issue 11: 82-108K tokens ⚠️
  • Issue 12: 88-127K tokens ⚠️
  • Total: 250-340K across 3 workflows

Recommended Structure (9 sub-issues):

  • Issue 10a: 35-45K tokens ✅
  • Issue 10b: 40-50K tokens ✅
  • Issue 10c: 25-35K tokens ✅
  • Issue 11a: 30-40K tokens ✅
  • Issue 11b: 35-45K tokens ✅
  • Issue 11c: 30-40K tokens ✅
  • Issue 12a: 45-55K tokens ✅
  • Issue 12b: 35-45K tokens ✅
  • Issue 12c: 40-50K tokens ✅
  • Total: 315-405K across 9 workflows

Why Break Down?

Token Efficiency:

  • Smaller context per workflow
  • Better prompt caching
  • Less redundant file loading
  • More targeted implementations

Risk Management:

  • Smaller changes easier to validate
  • Can roll back individual pieces
  • Test incrementally
  • Clearer failure isolation

Development Experience:

  • Faster ADW iterations
  • Clearer progress tracking
  • Better git history (smaller commits)
  • Easier to review

Cost Savings:

  • Estimated 20-30% token reduction from better caching
  • Fewer failed workflows (smaller scope = less complexity)
  • Less context re-loading

Proposed Issue Sequence

Execute in this order for best results:

Wave 1: App Structure

  1. Issue 10a - Move Frontend Application
  2. Issue 10b - Reorganize Backend Structure
  3. Issue 10c - Integration & Cleanup

Validate: Full stack works with new structure

Wave 2: Documentation

  1. Issue 11a - Documentation Structure & Indexes
  2. Issue 11b - Move Feature Docs & Specs
  3. Issue 11c - Move Issue Tracking Files

Validate: All documentation is self-contained

Wave 3: Extraction

  1. Issue 12a - Dependency Audit & Resolution
  2. Issue 12b - Extraction Tooling
  3. Issue 12c - Documentation & Final Validation

Validate: Extraction works, project is standalone

Implementation Notes

Inter-Issue Dependencies

Critical Dependencies:

  • 10b depends on 10a (frontend must move first)
  • 10c depends on 10a + 10b (integration needs both)
  • 11b depends on 11a (structure must exist)
  • 11c depends on 11a (structure must exist)
  • 12b depends on 12a (tooling should reflect audit findings)
  • 12c depends on 12a + 12b (validates everything)

Soft Dependencies:

  • Wave 2 should wait for Wave 1 completion (docs reference new structure)
  • Wave 3 should wait for Wave 1 + 2 (validates complete state)

Validation Checkpoints

After each wave:

  • Run full test suite
  • Test manual workflows
  • Verify no regressions
  • Update issue tracking

Rollback Strategy

Each sub-issue is small enough to:

  • Git revert if needed
  • Re-run with modifications
  • Debug in isolation

Cost-Benefit Analysis

Monolithic Approach (3 issues)

Pros:

  • Fewer GitHub issues to manage
  • Less administrative overhead
  • Simpler dependency tracking

Cons:

  • High token usage (80-127K per issue)
  • Higher failure risk
  • Harder to debug
  • Longer execution time
  • More expensive per workflow

Breakdown Approach (9 sub-issues)

Pros:

  • Optimal token usage (25-55K per issue)
  • Lower failure risk
  • Easier debugging
  • Faster iterations
  • Better caching efficiency
  • Clearer progress

Cons:

  • More GitHub issues to track
  • More ADW workflow executions
  • More validation checkpoints

Recommendation: Breakdown approach - benefits far outweigh costs

Token Optimization Techniques

For each sub-issue:

  1. Lazy Loading: Only load files being modified
  2. Targeted Context: Use grep/glob instead of full reads
  3. Incremental Validation: Test after each phase
  4. Cache Leverage: Keep similar file types together
  5. Focused Scope: Single responsibility per sub-issue

Conclusion

STRONG RECOMMENDATION: Break down all three issues into 9 sub-issues.

Expected Outcomes:

  • 20-30% token savings from better caching
  • 40-50% reduction in per-workflow token usage
  • Higher success rate (smaller scope)
  • Easier validation and debugging
  • Better git history

Total ADW Executions: 9 workflows (vs 3 monolithic) Total Token Usage: ~315-405K (vs 250-340K but with better distribution) Success Probability: Much higher with smaller, focused issues

Next Step: Create the 9 sub-issue markdown files with refined scope and clear dependencies.