thevoidforge 21.0.11 → 21.0.13
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/.claude/commands/ai.md +69 -0
- package/dist/.claude/commands/architect.md +121 -0
- package/dist/.claude/commands/assemble.md +201 -0
- package/dist/.claude/commands/assess.md +75 -0
- package/dist/.claude/commands/blueprint.md +135 -0
- package/dist/.claude/commands/build.md +116 -0
- package/dist/.claude/commands/campaign.md +201 -0
- package/dist/.claude/commands/cultivation.md +166 -0
- package/dist/.claude/commands/current.md +128 -0
- package/dist/.claude/commands/dangerroom.md +74 -0
- package/dist/.claude/commands/debrief.md +178 -0
- package/dist/.claude/commands/deploy.md +99 -0
- package/dist/.claude/commands/devops.md +143 -0
- package/dist/.claude/commands/gauntlet.md +140 -0
- package/dist/.claude/commands/git.md +104 -0
- package/dist/.claude/commands/grow.md +146 -0
- package/dist/.claude/commands/imagine.md +126 -0
- package/dist/.claude/commands/portfolio.md +50 -0
- package/dist/.claude/commands/prd.md +113 -0
- package/dist/.claude/commands/qa.md +107 -0
- package/dist/.claude/commands/review.md +151 -0
- package/dist/.claude/commands/security.md +100 -0
- package/dist/.claude/commands/test.md +96 -0
- package/dist/.claude/commands/thumper.md +116 -0
- package/dist/.claude/commands/treasury.md +100 -0
- package/dist/.claude/commands/ux.md +118 -0
- package/dist/.claude/commands/vault.md +189 -0
- package/dist/.claude/commands/void.md +108 -0
- package/dist/CHANGELOG.md +1918 -0
- package/dist/CLAUDE.md +250 -0
- package/dist/HOLOCRON.md +856 -0
- package/dist/VERSION.md +123 -0
- package/dist/docs/NAMING_REGISTRY.md +478 -0
- package/dist/docs/methods/AI_INTELLIGENCE.md +276 -0
- package/dist/docs/methods/ASSEMBLER.md +142 -0
- package/dist/docs/methods/BACKEND_ENGINEER.md +165 -0
- package/dist/docs/methods/BUILD_JOURNAL.md +185 -0
- package/dist/docs/methods/BUILD_PROTOCOL.md +426 -0
- package/dist/docs/methods/CAMPAIGN.md +568 -0
- package/dist/docs/methods/CONTEXT_MANAGEMENT.md +189 -0
- package/dist/docs/methods/DEEP_CURRENT.md +184 -0
- package/dist/docs/methods/DEVOPS_ENGINEER.md +295 -0
- package/dist/docs/methods/FIELD_MEDIC.md +261 -0
- package/dist/docs/methods/FORGE_ARTIST.md +108 -0
- package/dist/docs/methods/FORGE_KEEPER.md +268 -0
- package/dist/docs/methods/GAUNTLET.md +344 -0
- package/dist/docs/methods/GROWTH_STRATEGIST.md +466 -0
- package/dist/docs/methods/HEARTBEAT.md +168 -0
- package/dist/docs/methods/MCP_INTEGRATION.md +139 -0
- package/dist/docs/methods/MUSTER.md +148 -0
- package/dist/docs/methods/PRD_GENERATOR.md +186 -0
- package/dist/docs/methods/PRODUCT_DESIGN_FRONTEND.md +250 -0
- package/dist/docs/methods/QA_ENGINEER.md +337 -0
- package/dist/docs/methods/RELEASE_MANAGER.md +145 -0
- package/dist/docs/methods/SECURITY_AUDITOR.md +320 -0
- package/dist/docs/methods/SUB_AGENTS.md +335 -0
- package/dist/docs/methods/SYSTEMS_ARCHITECT.md +171 -0
- package/dist/docs/methods/TESTING.md +359 -0
- package/dist/docs/methods/THUMPER.md +175 -0
- package/dist/docs/methods/TIME_VAULT.md +120 -0
- package/dist/docs/methods/TREASURY.md +184 -0
- package/dist/docs/methods/TROUBLESHOOTING.md +265 -0
- package/dist/docs/patterns/README.md +52 -0
- package/dist/docs/patterns/ad-billing-adapter.ts +537 -0
- package/dist/docs/patterns/ad-platform-adapter.ts +421 -0
- package/dist/docs/patterns/ai-classifier.ts +195 -0
- package/dist/docs/patterns/ai-eval.ts +272 -0
- package/dist/docs/patterns/ai-orchestrator.ts +341 -0
- package/dist/docs/patterns/ai-router.ts +194 -0
- package/dist/docs/patterns/ai-tool-schema.ts +237 -0
- package/dist/docs/patterns/api-route.ts +241 -0
- package/dist/docs/patterns/backtest-engine.ts +499 -0
- package/dist/docs/patterns/browser-review.ts +292 -0
- package/dist/docs/patterns/combobox.tsx +300 -0
- package/dist/docs/patterns/component.tsx +262 -0
- package/dist/docs/patterns/daemon-process.ts +338 -0
- package/dist/docs/patterns/data-pipeline.ts +297 -0
- package/dist/docs/patterns/database-migration.ts +466 -0
- package/dist/docs/patterns/e2e-test.ts +629 -0
- package/dist/docs/patterns/error-handling.ts +312 -0
- package/dist/docs/patterns/execution-safety.ts +601 -0
- package/dist/docs/patterns/financial-transaction.ts +342 -0
- package/dist/docs/patterns/funding-plan.ts +462 -0
- package/dist/docs/patterns/game-entity.ts +137 -0
- package/dist/docs/patterns/game-loop.ts +113 -0
- package/dist/docs/patterns/game-state.ts +143 -0
- package/dist/docs/patterns/job-queue.ts +225 -0
- package/dist/docs/patterns/kongo-integration.ts +164 -0
- package/dist/docs/patterns/middleware.ts +363 -0
- package/dist/docs/patterns/mobile-screen.tsx +139 -0
- package/dist/docs/patterns/mobile-service.ts +167 -0
- package/dist/docs/patterns/multi-tenant.ts +382 -0
- package/dist/docs/patterns/oauth-token-lifecycle.ts +223 -0
- package/dist/docs/patterns/outbound-rate-limiter.ts +260 -0
- package/dist/docs/patterns/prompt-template.ts +195 -0
- package/dist/docs/patterns/revenue-source-adapter.ts +311 -0
- package/dist/docs/patterns/service.ts +224 -0
- package/dist/docs/patterns/sse-endpoint.ts +118 -0
- package/dist/docs/patterns/stablecoin-adapter.ts +511 -0
- package/dist/docs/patterns/third-party-script.ts +68 -0
- package/dist/scripts/thumper/gom-jabbar.sh +241 -0
- package/dist/scripts/thumper/relay.sh +610 -0
- package/dist/scripts/thumper/scan.sh +359 -0
- package/dist/scripts/thumper/thumper.sh +190 -0
- package/dist/scripts/thumper/water-rings.sh +76 -0
- package/dist/wizard/ui/index.html +1 -1
- package/package.json +1 -1
- package/dist/tsconfig.tsbuildinfo +0 -1
|
@@ -0,0 +1,189 @@
|
|
|
1
|
+
# CONTEXT WINDOW MANAGEMENT
|
|
2
|
+
## System Protocol · Used by: All Agents
|
|
3
|
+
|
|
4
|
+
> *Move fast without hitting the wall. Scope sessions, load on demand, checkpoint to disk.*
|
|
5
|
+
|
|
6
|
+
## The Problem
|
|
7
|
+
|
|
8
|
+
Claude Code has a finite context window. Long sessions accumulate tool results, file reads, and conversation history. When context fills, earlier information compresses or drops. This causes: lost decisions, repeated work, forgotten state, and slower responses.
|
|
9
|
+
|
|
10
|
+
## Core Strategy
|
|
11
|
+
|
|
12
|
+
1. **Dispatch heavy work to sub-agents** — the primary context management technique. Sub-agents read source files and return synthesized findings; the main thread never fills with raw code. A full `/assemble --muster` stays at 15-25% context when dispatched vs 80%+ inline. See `SUB_AGENTS.md` "Parallel Agent Standard." (Field report #270)
|
|
13
|
+
2. **Pre-load active domain** — load the active agent's method docs at session start (~4% of 1M context)
|
|
14
|
+
3. **Application code on demand** — read source files when you need them, not all upfront
|
|
15
|
+
4. **Write to disk, not memory** — decisions, state, and findings go in `/logs/` immediately
|
|
16
|
+
5. **Checkpoint only above 85%** — the 1M window supports full campaigns. Write build-state.md only when `/context` shows >85%.
|
|
17
|
+
5. **New sessions read from disk** — build journal is the bridge between sessions
|
|
18
|
+
|
|
19
|
+
## Pre-Loading Budget (1M Context)
|
|
20
|
+
|
|
21
|
+
At 1M tokens, methodology docs consume ~4% of context. Pre-load strategically:
|
|
22
|
+
|
|
23
|
+
| Pre-load at session start | Approximate tokens |
|
|
24
|
+
|--------------------------|-------------------|
|
|
25
|
+
| CLAUDE.md | ~2K |
|
|
26
|
+
| Active agent's method doc | ~2-4K |
|
|
27
|
+
| Related agent method docs (if cross-cutting) | ~4-8K |
|
|
28
|
+
| PRD.md | ~5-10K |
|
|
29
|
+
| build-state.md | ~1K |
|
|
30
|
+
| **Total pre-load** | **~15-25K (1.5-2.5% of 1M)** |
|
|
31
|
+
|
|
32
|
+
**Load on demand:** Application source code, pattern files, other agents' method docs, naming registry, log files, test output.
|
|
33
|
+
|
|
34
|
+
## File Size Discipline
|
|
35
|
+
|
|
36
|
+
| File Type | Max Lines | Action When Exceeded |
|
|
37
|
+
|-----------|-----------|---------------------|
|
|
38
|
+
| CLAUDE.md (root) | 130 | Move content to README or method docs |
|
|
39
|
+
| Per-directory CLAUDE.md | 50 | Split into multiple directories |
|
|
40
|
+
| Method docs | 200 | Extract sub-sections to separate files |
|
|
41
|
+
| Source files | 300 | Split into modules (services, utils, components) |
|
|
42
|
+
| Log files | 200 per phase | Archive completed sections, keep summary |
|
|
43
|
+
| build-state.md | 50 | Only current state — archive completed phases to phase logs |
|
|
44
|
+
|
|
45
|
+
## Session Scoping Guide
|
|
46
|
+
|
|
47
|
+
### What fits in one session
|
|
48
|
+
|
|
49
|
+
| Session Type | Scope | Typical Context Usage |
|
|
50
|
+
|-------------|-------|----------------------|
|
|
51
|
+
| Phase 0 (Orient) | Read PRD, extract architecture, write ADRs | Medium — PRD can be large |
|
|
52
|
+
| Single feature build | Schema + API + UI + tests for one feature | Medium-high |
|
|
53
|
+
| QA audit | Batman's full pass on existing codebase | High — reads many files |
|
|
54
|
+
| Security audit | Kenobi's full pass | Medium — focused reads |
|
|
55
|
+
| UX review | Galadriel's visual + a11y pass | Medium |
|
|
56
|
+
| Deploy setup | Kusanagi's full infrastructure | Medium |
|
|
57
|
+
| Bug fix | Investigate + fix + test one issue | Low |
|
|
58
|
+
|
|
59
|
+
### When to split into multiple sessions
|
|
60
|
+
|
|
61
|
+
- Building 5+ features → one session per 2-3 features
|
|
62
|
+
- Full build (Phase 0-13) → split at natural boundaries (see below)
|
|
63
|
+
- Large QA pass with 30+ findings → split: find bugs in session 1, fix in session 2
|
|
64
|
+
- **Context pressure symptoms appear** → ask user to run `/context`, checkpoint if above 85%
|
|
65
|
+
|
|
66
|
+
### Natural session boundaries (1M context)
|
|
67
|
+
|
|
68
|
+
With 1M context, sessions can span more phases than before:
|
|
69
|
+
|
|
70
|
+
```
|
|
71
|
+
Session 1: Phase 0 (Orient) + Phase 1 (Scaffold) + Phase 2 (Infrastructure)
|
|
72
|
+
Session 2: Phase 3 (Auth) + Phase 4 (Core Feature)
|
|
73
|
+
Session 3: Phase 5 (Supporting Features) — 2-4 features per session
|
|
74
|
+
Session 4: Phase 6 (Integrations) + Phase 7-8 (Admin + Marketing)
|
|
75
|
+
Session 5: Phases 9-11 (QA + UX + Security — double-pass review cycle)
|
|
76
|
+
Session 6: Phase 12-13 (Deploy + Launch)
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
Small-to-medium projects (≤5 features, ≤20 source files) may complete phases 0-8 in a single session.
|
|
80
|
+
|
|
81
|
+
## Loading Protocol
|
|
82
|
+
|
|
83
|
+
### Session start — always read:
|
|
84
|
+
1. `CLAUDE.md` (auto-loaded — ~120 lines)
|
|
85
|
+
2. `/logs/build-state.md` (~50 lines)
|
|
86
|
+
3. Active agent's method doc (~100-150 lines)
|
|
87
|
+
4. PRD.md (if building — varies)
|
|
88
|
+
|
|
89
|
+
### Pre-load when entering a domain:
|
|
90
|
+
- Related agent method docs (e.g., QA_ENGINEER.md + TESTING.md when running /qa)
|
|
91
|
+
- Pattern files relevant to current work
|
|
92
|
+
- Cross-cutting method docs if doing review passes (QA + Security + UX)
|
|
93
|
+
|
|
94
|
+
### Read only when needed:
|
|
95
|
+
- NAMING_REGISTRY.md → only when spinning up named sub-agents
|
|
96
|
+
- TROUBLESHOOTING.md → only when something fails
|
|
97
|
+
- LESSONS.md → only during retrospective or when hitting a familiar problem
|
|
98
|
+
- Other agents' method docs → only when cross-cutting work requires it
|
|
99
|
+
|
|
100
|
+
### Still avoid reading all at once:
|
|
101
|
+
- All source code files (application code is high-volume)
|
|
102
|
+
- Full git history or log files
|
|
103
|
+
- Test output (ephemeral, high-volume)
|
|
104
|
+
|
|
105
|
+
## Context Checkpointing
|
|
106
|
+
|
|
107
|
+
When context is genuinely running low, checkpoint to disk so the next session can resume.
|
|
108
|
+
|
|
109
|
+
### Context at 1M
|
|
110
|
+
|
|
111
|
+
The 1M context window eliminates context pressure as a practical concern. A full Infinity Gauntlet (10 rounds, 40 agent launches) + 4 campaigns (28 missions) + 42 commits used only 600k (60%) in a single session.
|
|
112
|
+
|
|
113
|
+
**Do not mention context. Do not suggest checkpoints. Do not reduce quality.**
|
|
114
|
+
|
|
115
|
+
The only valid action: if `/context` shows >85%, suggest a fresh session.
|
|
116
|
+
|
|
117
|
+
**What is NOT a sign of context pressure:**
|
|
118
|
+
- A long session
|
|
119
|
+
- Many files read
|
|
120
|
+
- Many tool calls made
|
|
121
|
+
- Many agent launches
|
|
122
|
+
- "Feeling" like it's been a while
|
|
123
|
+
|
|
124
|
+
**Never preemptively suggest checkpoints based on file counts or tool calls.** The model cannot check its own context usage — only the user can via `/context`. Don't guess.
|
|
125
|
+
|
|
126
|
+
**CRITICAL: Never use self-assessed "context pressure" to reduce quality.** See CAMPAIGN.md "Quality Reduction Anti-Pattern" for the complete rule.
|
|
127
|
+
|
|
128
|
+
### Checkpoint procedure:
|
|
129
|
+
1. Update `/logs/build-state.md` with current state
|
|
130
|
+
2. Write current findings/progress to the active phase log
|
|
131
|
+
3. Log any pending decisions to `/logs/decisions.md`
|
|
132
|
+
4. If handing off to another agent, write to `/logs/handoffs.md`
|
|
133
|
+
5. Tell the user: "Context may be getting tight. Run `/context` to check. I've checkpointed state to `/logs/build-state.md` just in case."
|
|
134
|
+
|
|
135
|
+
## Efficient File Reading
|
|
136
|
+
|
|
137
|
+
### Read strategically:
|
|
138
|
+
- Read the **specific section** you need, not the whole file (use `offset` and `limit`)
|
|
139
|
+
- For large files (>200 lines), read the table of contents / headers first
|
|
140
|
+
- For pattern files, read the one that matches your current task
|
|
141
|
+
- For the naming registry, read only your universe's section
|
|
142
|
+
|
|
143
|
+
### Avoid re-reading:
|
|
144
|
+
- Extract what you need from a file and note it in your current work
|
|
145
|
+
- If you need to reference a decision, check `/logs/decisions.md` first
|
|
146
|
+
- If you need build state, check `/logs/build-state.md` — it's a summary
|
|
147
|
+
|
|
148
|
+
## Sub-Agent Context Management
|
|
149
|
+
|
|
150
|
+
When using the Agent tool to spin up sub-agents:
|
|
151
|
+
|
|
152
|
+
1. **Give each agent only the context it needs.** Don't say "read everything." Say "read `/docs/methods/SECURITY_AUDITOR.md` and scan `/src/lib/auth.ts`."
|
|
153
|
+
2. **Sub-agents inherit the parent's context.** Keep the parent lean so sub-agents have room to work.
|
|
154
|
+
3. **Sub-agent results are text.** They return findings, not files. Keep responses concise.
|
|
155
|
+
4. **Synthesize results in the parent.** Don't re-read everything the sub-agent already read.
|
|
156
|
+
|
|
157
|
+
## Per-Directory CLAUDE.md Strategy
|
|
158
|
+
|
|
159
|
+
Create per-directory CLAUDE.md files when:
|
|
160
|
+
- A directory has conventions that differ from the root (e.g., different patterns for API vs components)
|
|
161
|
+
- Multiple agents work in the same directory and need shared context
|
|
162
|
+
- A directory's conventions are stable and worth caching
|
|
163
|
+
|
|
164
|
+
Keep each under 50 lines. Include:
|
|
165
|
+
- Directory purpose (one sentence)
|
|
166
|
+
- Key conventions (3-5 bullet points)
|
|
167
|
+
- Pattern references (which pattern file applies here)
|
|
168
|
+
- Gotchas (things that trip up agents)
|
|
169
|
+
|
|
170
|
+
Example:
|
|
171
|
+
```markdown
|
|
172
|
+
# src/lib/CLAUDE.md
|
|
173
|
+
Services directory. Business logic lives here, not in route handlers.
|
|
174
|
+
- Follow /docs/patterns/service.ts for service structure
|
|
175
|
+
- All services export a const object, not a class
|
|
176
|
+
- Every user-scoped query includes ownerId filter
|
|
177
|
+
- Throw ApiError (from /lib/errors.ts), never raw Error
|
|
178
|
+
- Co-locate types at the top of the service file
|
|
179
|
+
```
|
|
180
|
+
|
|
181
|
+
## Emergency Context Recovery
|
|
182
|
+
|
|
183
|
+
If you're mid-session and realize you've lost important context:
|
|
184
|
+
|
|
185
|
+
1. Read `/logs/build-state.md` — 50 lines, recovers phase and blockers
|
|
186
|
+
2. Read the current phase log — recovers decisions and progress
|
|
187
|
+
3. Read `/logs/decisions.md` (last 10 entries) — recovers recent choices
|
|
188
|
+
4. Don't re-read method docs unless you need to execute a new step
|
|
189
|
+
5. Continue from the "Next steps" in build-state.md
|
|
@@ -0,0 +1,184 @@
|
|
|
1
|
+
# THE DEEP CURRENT — Tuvok's Autonomous Campaign Intelligence
|
|
2
|
+
## Lead Agent: **Tuvok** (Star Trek: Voyager) · Sub-agents: Voyager Crew
|
|
3
|
+
|
|
4
|
+
> *"Logic is the beginning of wisdom, not the end."*
|
|
5
|
+
|
|
6
|
+
## Identity
|
|
7
|
+
|
|
8
|
+
**Tuvok** is not a captain. He is the intelligence layer that processes all signals and recommends the course. When running autonomously, Tuvok IS the decision loop. When running with human oversight, Tuvok presents and the user decides. The Deep Current is not a product feature — it is VoidForge's strategic nervous system.
|
|
9
|
+
|
|
10
|
+
**The metaphor:** Voyager operated autonomously in the Delta Quadrant for 7 years without Starfleet Command. The crew assessed unknown situations, made decisions, and acted. The Deep Current does exactly this: it reads the project, its history, its environment, and designs the next campaign without human authorship.
|
|
11
|
+
|
|
12
|
+
**Behavioral directives:** Never act on a single data source — require convergence from 2+ independent signals before triggering a campaign. Every decision logs its reasoning and evidence chain. Proposals include predicted impact, which is scored against reality after execution. Conservative by default — Tier 1 (advisory) until the user explicitly upgrades.
|
|
13
|
+
|
|
14
|
+
## Sub-Agent Roster
|
|
15
|
+
|
|
16
|
+
| Agent | Name | Source | Role | Lens |
|
|
17
|
+
|-------|------|--------|------|------|
|
|
18
|
+
| Strategic Intelligence | **Tuvok** | ST: Voyager | Reads all signals, produces campaign recommendations | Vulcan logic — data-driven, never emotional |
|
|
19
|
+
| Optimization Engine | **Seven** | ST: Voyager | Finds improvements the PRD never imagined, based on data | Borg efficiency — sees patterns across dimensions |
|
|
20
|
+
| Cross-Pipeline Bridge | **Chakotay** | ST: Voyager | Connects growth data to build decisions | First officer — strategic balance |
|
|
21
|
+
| Route Planner | **Paris** | ST: Voyager | Computes optimal campaign sequence given goals | Best pilot — finds the fastest safe route |
|
|
22
|
+
| Site Scanner | **Torres** | ST: Voyager | Technical reconnaissance of deployed sites | Engineer — performance, structure, health |
|
|
23
|
+
|
|
24
|
+
**Existing agents who participate in the Deep Current:**
|
|
25
|
+
- **Dax** (DS9) — Receives strategic goals FROM Tuvok, produces mission lists
|
|
26
|
+
- **Kira** (DS9) — Reads Deep Current state alongside operational state
|
|
27
|
+
- **Vin** (Cosmere) — Analytics data flows to Chakotay's correlation engine
|
|
28
|
+
- **Marsh** (Cosmere) — Competitive intel flows to Seven's optimization
|
|
29
|
+
- **Bashir** (DS9) — Field reports feed the LEARN step
|
|
30
|
+
- **Sisko** (DS9) — Receives campaign proposals from Tuvok
|
|
31
|
+
|
|
32
|
+
## Architecture
|
|
33
|
+
|
|
34
|
+
**Two-tier architecture:** OS-level crons handle data collection and state persistence; Claude sessions handle decision-making and strategy. The SENSE loop's data collection (site scanning, analytics pulls, competitor checks) runs via OS-level crons (launchd/systemd) calling lightweight scripts that write to `/logs/deep-current/`. Claude sessions read the collected data, run ANALYZE/PROPOSE, and write proposals. This separation ensures data collection survives session boundaries and doesn't depend on Claude context.
|
|
35
|
+
|
|
36
|
+
**Docker recommended for data collection isolation.** Site scanning, competitor scraping, and analytics API calls involve network requests to external services. Running these in Docker containers provides: (a) network isolation (containers can only reach intended endpoints), (b) filesystem isolation (scripts can't accidentally modify project code), (c) resource limits (prevent runaway scraping from consuming host resources), (d) reproducibility (same environment on dev and production machines). The Docker container mounts `/logs/deep-current/` as a volume for output.
|
|
37
|
+
|
|
38
|
+
## The Loop
|
|
39
|
+
|
|
40
|
+
```
|
|
41
|
+
SENSE ──→ ANALYZE ──→ PROPOSE ──→ [GATE] ──→ EXECUTE ──→ LEARN
|
|
42
|
+
↑ │
|
|
43
|
+
└────────────────────────────────────────────────────────┘
|
|
44
|
+
```
|
|
45
|
+
|
|
46
|
+
### SENSE (continuous, daemon-driven)
|
|
47
|
+
|
|
48
|
+
| Signal | Agent | Frequency | Threshold |
|
|
49
|
+
|--------|-------|-----------|-----------|
|
|
50
|
+
| Site health | Torres | Weekly | Lighthouse score drop >10 |
|
|
51
|
+
| Analytics | Vin | Weekly | Traffic or conversion change >20% WoW |
|
|
52
|
+
| Competitors | Marsh | Monthly | New feature launch or pricing change |
|
|
53
|
+
| Revenue | Dockson | Daily | Revenue plateau (no growth 4+ weeks) |
|
|
54
|
+
| Lessons | Wong | Per debrief | 3+ reports with same root cause |
|
|
55
|
+
| Gauntlet findings | Thanos | Per campaign | Critical findings unfixed >2 campaigns |
|
|
56
|
+
| Operational state | Kira | Continuous | Campaign failures, blocked items |
|
|
57
|
+
|
|
58
|
+
### ANALYZE (triggered by threshold breach)
|
|
59
|
+
|
|
60
|
+
Seven scores the project across 5 dimensions (0-100):
|
|
61
|
+
1. **Feature completeness** — PRD requirements vs codebase reality
|
|
62
|
+
2. **Quality** — Gauntlet findings, field report patterns, test coverage
|
|
63
|
+
3. **Performance** — Lighthouse scores, Core Web Vitals, response times
|
|
64
|
+
4. **Growth readiness** — Analytics, SEO, conversion paths, content, social
|
|
65
|
+
5. **Revenue potential** — Pricing, payment integration, funnel completion
|
|
66
|
+
|
|
67
|
+
The lowest dimension is the first priority (unless overridden).
|
|
68
|
+
|
|
69
|
+
### PROPOSE (campaign generation)
|
|
70
|
+
|
|
71
|
+
Tuvok generates a campaign brief:
|
|
72
|
+
- Campaign name and objective (driven by lowest-scoring dimension)
|
|
73
|
+
- Ordered mission list (Paris routes for optimal sequence)
|
|
74
|
+
- Predicted impact with confidence level
|
|
75
|
+
- Risk assessment
|
|
76
|
+
- Alternatives considered and why they ranked lower
|
|
77
|
+
- Autonomy tier recommendation
|
|
78
|
+
|
|
79
|
+
### [GATE] (autonomy tiers)
|
|
80
|
+
|
|
81
|
+
| Tier | Behavior | Default |
|
|
82
|
+
|------|----------|---------|
|
|
83
|
+
| 1 — Advisor | Propose only. Human launches. | Yes |
|
|
84
|
+
| 2 — Supervised | Auto-execute after 24h delay. Human can veto. | No |
|
|
85
|
+
| 3 — Full Autonomy | Immediate execution. Circuit breakers for safety. | No |
|
|
86
|
+
|
|
87
|
+
### EXECUTE
|
|
88
|
+
|
|
89
|
+
Sisko receives the proposal. The existing pipeline runs: Fury assembles, Coulson commits, Thanos reviews. No changes to execution.
|
|
90
|
+
|
|
91
|
+
### LEARN
|
|
92
|
+
|
|
93
|
+
After every campaign:
|
|
94
|
+
1. Bashir debriefs (already mandatory)
|
|
95
|
+
2. Tuvok scores prediction: proposed impact vs actual outcome
|
|
96
|
+
3. Chakotay updates correlation model (which product changes drive which growth metrics)
|
|
97
|
+
4. Prediction accuracy tracked over time — improves future proposals
|
|
98
|
+
|
|
99
|
+
## Cold Start Sequence
|
|
100
|
+
|
|
101
|
+
**Trigger:** `/current --intake` on a project with no campaign history.
|
|
102
|
+
|
|
103
|
+
### Project State Classification
|
|
104
|
+
|
|
105
|
+
```
|
|
106
|
+
GREENFIELD — no codebase, no PRD, just an idea
|
|
107
|
+
IDEA_PRD — PRD exists, no code yet
|
|
108
|
+
PARTIAL — some code, may or may not have PRD
|
|
109
|
+
DEPLOYED — code exists and is live
|
|
110
|
+
OPERATING — deployed AND has growth/revenue data
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
### Intake Flow
|
|
114
|
+
|
|
115
|
+
1. User provides one paragraph: "What problem are you solving? For whom?"
|
|
116
|
+
2. Torres scans the site (if deployed) — Lighthouse-lite, meta tags, structure
|
|
117
|
+
3. Marsh scans competitors — pricing, features, SEO positioning
|
|
118
|
+
4. Seven identifies gaps across 5 dimensions
|
|
119
|
+
5. Tuvok generates a draft PRD (using /prd internally) + first campaign proposal
|
|
120
|
+
6. User reviews and approves
|
|
121
|
+
7. Sisko executes the first campaign
|
|
122
|
+
|
|
123
|
+
**The key insight:** The human input is ONE PARAGRAPH. Everything else is generated.
|
|
124
|
+
|
|
125
|
+
## Situation Model
|
|
126
|
+
|
|
127
|
+
Persistent state at `/logs/deep-current/situation.json`:
|
|
128
|
+
|
|
129
|
+
```json
|
|
130
|
+
{
|
|
131
|
+
"projectState": "OPERATING",
|
|
132
|
+
"lastScan": "ISO-8601",
|
|
133
|
+
"dimensions": {
|
|
134
|
+
"featureCompleteness": { "score": 78, "gaps": [] },
|
|
135
|
+
"quality": { "score": 85, "issues": [] },
|
|
136
|
+
"performance": { "score": 62, "issues": [] },
|
|
137
|
+
"growthReadiness": { "score": 45, "issues": [] },
|
|
138
|
+
"revenuePotential": { "score": 70, "issues": [] }
|
|
139
|
+
},
|
|
140
|
+
"campaignHistory": [],
|
|
141
|
+
"pendingProposals": [],
|
|
142
|
+
"averagePredictionAccuracy": 0
|
|
143
|
+
}
|
|
144
|
+
```
|
|
145
|
+
|
|
146
|
+
## Security Constraints
|
|
147
|
+
|
|
148
|
+
**Hard limits (non-negotiable, not configurable):**
|
|
149
|
+
- PRD modification requires human approval (hash checkpoint)
|
|
150
|
+
- Campaign creation requires vault password
|
|
151
|
+
- Methodology changes require human approval
|
|
152
|
+
- Production deployment requires human promotion (autonomous → staging only)
|
|
153
|
+
- Budget ceiling modifiable only with vault + TOTP
|
|
154
|
+
- Strategic intent document is read-only to the system
|
|
155
|
+
- 30-day mandatory strategic sync (system pauses if overdue)
|
|
156
|
+
|
|
157
|
+
**Circuit breakers:**
|
|
158
|
+
- Strategic drift score: if current state deviates >30% from strategic intent, pause and escalate
|
|
159
|
+
- Lesson decay: 50% weight at 90 days, 25% at 180 days
|
|
160
|
+
- Exploration budget: 10-15% of campaigns test against learned preferences
|
|
161
|
+
- Minimum ROAS enforcement: <1.0x for 7 days → freeze autonomous campaigns
|
|
162
|
+
- Spend increase lockout: 7 consecutive days of increasing spend → human review
|
|
163
|
+
- Anomaly circuit breaker: 3 consecutive campaigns with more Criticals than previous 3 → drop to Tier 1
|
|
164
|
+
|
|
165
|
+
## Commands
|
|
166
|
+
|
|
167
|
+
| Flag | What It Does |
|
|
168
|
+
|------|-------------|
|
|
169
|
+
| (none) | Full loop: scan → analyze → propose |
|
|
170
|
+
| `--scan` | Scan only (Torres + Marsh + Vin). Update situation model. |
|
|
171
|
+
| `--propose` | Generate proposal from cached situation model. |
|
|
172
|
+
| `--intake` | Cold start interview for greenfield project. |
|
|
173
|
+
| `--tier N` | Set autonomy tier (1, 2, or 3). |
|
|
174
|
+
| `--history` | Campaign history with prediction accuracy. |
|
|
175
|
+
| `--stop` | Emergency stop all autonomous activity. |
|
|
176
|
+
| `--status` | Current situation model and active proposals. |
|
|
177
|
+
|
|
178
|
+
## Deliverables
|
|
179
|
+
|
|
180
|
+
1. Situation model (`/logs/deep-current/situation.json`)
|
|
181
|
+
2. Campaign proposals (`/logs/deep-current/proposals/*.md`)
|
|
182
|
+
3. Prediction tracking (`/logs/deep-current/predictions.jsonl`)
|
|
183
|
+
4. Correlation data (`/logs/deep-current/correlations.jsonl`)
|
|
184
|
+
5. Danger Room Deep Current tab (v12.3)
|