This commit is contained in:
92
docs/wiki-test/concepts/development-velocity.md
Normal file
92
docs/wiki-test/concepts/development-velocity.md
Normal file
@@ -0,0 +1,92 @@
|
||||
---
|
||||
type: concept
|
||||
name: Development Velocity
|
||||
confidence: 0.95
|
||||
sources: 14
|
||||
last_compiled: 2026-04-13
|
||||
---
|
||||
|
||||
# Development Velocity
|
||||
|
||||
## Summary
|
||||
|
||||
This page synthesizes patterns across 20 development sessions to understand
|
||||
how [[Waggle OS]] actually gets built — what works, what doesn't, and what
|
||||
the data says about productivity.
|
||||
|
||||
No single session handoff contains this analysis. It emerges from looking
|
||||
across all of them.
|
||||
|
||||
## Velocity by Phase
|
||||
|
||||
| Period | Sessions | Commits | Key Output |
|
||||
|--------|----------|---------|------------|
|
||||
| Mar 27-31 | 5 | ~10 | M2 sprint: P0 fixes, resilience, cleanup |
|
||||
| Apr 1-5 | 4 | ~8 | Deep refactoring, multiple audit rounds |
|
||||
| Apr 6-7 | 2 | ~6 | Agent intelligence sprint (9 features, 112 tests) |
|
||||
| Apr 8 | 1 | 6 | Structural refactors (chat.ts, personas.ts split) |
|
||||
| Apr 9-10 | 2 | 11 | ULTRAPLAN Phases 1-9 (120 files, 17K lines) |
|
||||
| Apr 11 | 1 | 17 | Phases A+B (12 feature + 5 polish commits) |
|
||||
| Apr 12 | 5 | ~30 | Phases C+D, E2E, tier restructure, binary |
|
||||
| Apr 13 | 2 | 33 | Entire backlog + Memory MCP + Wiki Compiler spec |
|
||||
|
||||
**Total: ~20 sessions, ~120 commits, 18 days from "all broken" to backlog cleared.**
|
||||
|
||||
## What Accelerated
|
||||
|
||||
1. **CLAUDE.md as contract.** Once the authoritative CLAUDE.md was in place
|
||||
(around Apr 8), sessions became dramatically more productive. The agent
|
||||
could self-direct against a clear spec instead of guessing.
|
||||
|
||||
2. **"You lead" delegation.** Marko's shift to *"yes whatever you choose you
|
||||
lead"* (Apr 12-13) enabled marathon autonomous sessions. 29 commits in a
|
||||
single session wouldn't happen with approval on every change.
|
||||
|
||||
3. **Memory handoffs.** Session handoff memory files let each new session pick
|
||||
up exactly where the last left off. No ramp-up time. The first message is
|
||||
"continue" and work starts immediately.
|
||||
|
||||
4. **Playwright over manual testing.** After Marko burned out on manual binary
|
||||
verification (Apr 12), switching to headless Playwright E2E removed the
|
||||
human bottleneck. 96 E2E tests replaced "click here, does it work?"
|
||||
|
||||
## What Slowed Down
|
||||
|
||||
1. **The "all broken" period (Apr 1).** Multiple restart cycles, CORS errors,
|
||||
vault invisible, agents returning "local mode." Lost ~half a day to
|
||||
debugging basic wiring issues.
|
||||
|
||||
2. **Audit fatigue (Apr 1).** Marko asked for 4+ full codebase audit rounds
|
||||
in a single day. Each audit found real issues, but diminishing returns
|
||||
set in. The fix: ship and iterate, not audit to perfection.
|
||||
|
||||
3. **Context resets.** New sessions without clear handoffs required re-reading
|
||||
the entire codebase state. The memory system solved this but took until
|
||||
Apr 8 to be fully operational.
|
||||
|
||||
4. **Binary build + test cycle.** Building the Tauri binary takes minutes.
|
||||
Testing it manually takes more. This blocked the feedback loop until
|
||||
Playwright replaced manual testing.
|
||||
|
||||
## The Mega Session Pattern
|
||||
|
||||
The most productive sessions follow a pattern:
|
||||
1. Clear handoff note from previous session
|
||||
2. Marko says "continue" or gives broad direction
|
||||
3. Agent reads state, makes a plan, executes autonomously
|
||||
4. Marko checks in periodically for strategic steering
|
||||
5. Session ends with detailed handoff note
|
||||
|
||||
The April 13 mega session (29 commits) is the purest example. Marko gave
|
||||
broad directives ("do team server", "compose new docker", "go for ollama")
|
||||
and the agent executed full feature implementations autonomously.
|
||||
|
||||
## Contradiction
|
||||
|
||||
The April 1 "audit everything" approach vs. the April 13 "you lead" approach
|
||||
represent opposite strategies. Both produced results, but the "you lead"
|
||||
approach produced 3-5x more output per session. The audit approach caught
|
||||
real bugs but also burned time on diminishing-return passes.
|
||||
|
||||
**Resolution:** The optimal pattern is likely: "you lead" for implementation,
|
||||
followed by one focused review pass (not 4).
|
||||
59
docs/wiki-test/concepts/mind-architecture.md
Normal file
59
docs/wiki-test/concepts/mind-architecture.md
Normal file
@@ -0,0 +1,59 @@
|
||||
---
|
||||
type: concept
|
||||
name: Mind Architecture
|
||||
confidence: 0.96
|
||||
sources: 6
|
||||
last_compiled: 2026-04-13
|
||||
related_entities:
|
||||
- Waggle OS
|
||||
---
|
||||
|
||||
# Mind Architecture
|
||||
|
||||
## Summary
|
||||
|
||||
The .mind file is [[Waggle OS]]'s core technical innovation — a single SQLite
|
||||
database per user or workspace that stores persistent memory in a 6-layer
|
||||
architecture inspired by video codecs (I-Frames and P-Frames).
|
||||
|
||||
## The 6 Layers
|
||||
|
||||
| Layer | Name | Content | Load Time | Size |
|
||||
|-------|------|---------|-----------|------|
|
||||
| 0 | Identity | WHO the agent is (name, role, personality) | <1ms | ~500 tokens |
|
||||
| 1 | Awareness | WHERE the agent is (active tasks, context) | <50ms | ~2000 tokens |
|
||||
| 2 | Memory Stream | I-Frames (snapshots) + P-Frames (deltas) | <200ms | Unbounded |
|
||||
| 3 | Knowledge Graph | Entities + typed relations + confidence | Query-time | Unbounded |
|
||||
| 4 | Session Store | Frame grouping by session/conversation | Query-time | Unbounded |
|
||||
| 5 | Embedding Index | sqlite-vec vectors for semantic search | Query-time | ~50MB |
|
||||
|
||||
## How Search Works
|
||||
|
||||
Hybrid search combining three strategies with Reciprocal Rank Fusion (RRF):
|
||||
1. **BM25** via FTS5 — catches exact keyword matches
|
||||
2. **Vector similarity** via sqlite-vec — catches semantic meaning
|
||||
3. **Knowledge Graph traversal** — catches relationship-based connections
|
||||
|
||||
## Key Design Decisions
|
||||
|
||||
- **SQLite, not Postgres:** Zero external dependencies. Embedded. Portable.
|
||||
A .mind file IS the memory — copy it, and the agent's memory travels with it.
|
||||
- **Video codec metaphor:** I-Frames are complete snapshots (like keyframes).
|
||||
P-Frames are deltas/updates. This enables efficient storage with temporal
|
||||
reconstruction.
|
||||
- **Confidence scoring:** Every entity and relation has a confidence score
|
||||
(0-1). Multiple sources reinforcing the same fact increase confidence.
|
||||
Contradictions lower it.
|
||||
- **Frame sources:** Every frame is tagged: user_stated, tool_verified,
|
||||
agent_inferred, system, import. This enables trust hierarchies.
|
||||
|
||||
## Scale
|
||||
|
||||
Target: ~500MB-1GB per .mind file per employee. Current personal.mind has 202
|
||||
frames and 2,734 entities. Production workloads expected to reach thousands
|
||||
of frames with sub-200ms query times.
|
||||
|
||||
## Relations
|
||||
|
||||
- [[Waggle OS]] — the product built on this architecture
|
||||
- [[LLM Provider Stack]] — how the agent routes LLM requests for memory operations
|
||||
Reference in New Issue
Block a user