v0.3.0 d226234

plan.md RawHistoryFolder

Implementation Plan: Native WebKit Browser Backend

Branch: 003-webkit2gtk-migration | Date: 2025-01-21 | Spec: spec.md Input: Feature specification from /home/brice/dev/projects/dumb-browser/specs/003-webkit2gtk-migration/spec.md

Execution Flow (/plan command scope)

1. Load feature spec from Input path
   → If not found: ERROR "No feature spec at {path}"
2. Fill Technical Context (scan for NEEDS CLARIFICATION)
   → Detect Project Type from context (web=frontend+backend, mobile=app+api)
   → Set Structure Decision based on project type
3. Evaluate Constitution Check section below
   → If violations exist: Document in Complexity Tracking
   → If no justification possible: ERROR "Simplify approach first"
   → Update Progress Tracking: Initial Constitution Check
4. Execute Phase 0 → research.md
   → If NEEDS CLARIFICATION remain: ERROR "Resolve unknowns"
5. Execute Phase 1 → contracts, data-model.md, quickstart.md, agent-specific template file (e.g., `CLAUDE.md` for Claude Code, `.github/copilot-instructions.md` for GitHub Copilot, or `GEMINI.md` for Gemini CLI).
6. Re-evaluate Constitution Check section
   → If new violations: Refactor design, return to Phase 1
   → Update Progress Tracking: Post-Design Constitution Check
7. Plan Phase 2 → Describe task generation approach (DO NOT create tasks.md)
8. STOP - Ready for /tasks command

IMPORTANT: The /plan command STOPS at step 7. Phases 2-4 are executed by other commands:

  • Phase 2: /tasks command creates tasks.md
  • Phase 3-4: Implementation execution (manual or via tools)

Summary

Replace Wails framework with direct WebKit2GTK bindings to gain full control over browser engine capabilities, maintain all existing functionality while removing framework limitations, and create custom C Go bindings in a pkg/ package for potential future extraction.

Technical Context

Language/Version: Go 1.25.1 + C bindings for WebKit2GTK
Primary Dependencies: WebKit2GTK, GTK3, CGO for C bindings
Storage: SQLite (maintain existing database schema and data)
Testing: Go testing + WebKit integration tests
Target Platform: Linux (Wayland/X11) - focus on GTK-based systems Project Type: single - native desktop application
Performance Goals: <500ms startup time, <100MB baseline memory, maintain existing performance
Constraints: Remove all Wails dependencies, preserve user data, maintain keyboard shortcuts and browser features
Scale/Scope: Single browser window, existing CLI functionality, WebKit2GTK reference clone for development

Constitution Check

GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.

Simplicity:

  • Projects: 1 (single native browser application)
  • Using framework directly? ✅ (Direct WebKit2GTK, removing Wails wrapper)
  • Single data model? ✅ (Maintain existing SQLite schema)
  • Avoiding patterns? ✅ (Direct C bindings, no unnecessary abstraction layers)

Architecture:

  • EVERY feature as library? ✅ (pkg/ package for WebKit bindings, reusable)
  • Libraries listed: pkg/webkit (WebKit2GTK Go bindings), existing internal packages
  • CLI per library: Maintain existing CLI, add webkit package testing commands
  • Library docs: llms.txt format planned for pkg/webkit

Testing (NON-NEGOTIABLE):

  • RED-GREEN-Refactor cycle enforced? ✅ (Contract tests for WebKit bindings first)
  • Git commits show tests before implementation? ✅ (Will create failing WebKit tests)
  • Order: Contract→Integration→E2E→Unit strictly followed? ✅
  • Real dependencies used? ✅ (Real WebKit2GTK, actual browser engine)
  • Integration tests for: WebKit bindings, browser functionality, keyboard shortcuts
  • FORBIDDEN: Implementation before test, skipping RED phase

Observability:

  • Structured logging included? ✅ (Continue using slog)
  • Frontend logs → backend? ✅ (WebKit console logs to Go backend)
  • Error context sufficient? ✅ (WebKit error propagation to Go)

Versioning:

  • Version number assigned? Next version after current (maintain semver)
  • BUILD increments on every change? ✅
  • Breaking changes handled? ✅ (Migration from Wails to native, preserve user data)

Project Structure

Documentation (this feature)

specs/[###-feature]/
├── plan.md              # This file (/plan command output)
├── research.md          # Phase 0 output (/plan command)
├── data-model.md        # Phase 1 output (/plan command)
├── quickstart.md        # Phase 1 output (/plan command)
├── contracts/           # Phase 1 output (/plan command)
└── tasks.md             # Phase 2 output (/tasks command - NOT created by /plan)

Source Code (repository root)

# Option 1: Single project (DEFAULT)
src/
├── models/
├── services/
├── cli/
└── lib/

tests/
├── contract/
├── integration/
└── unit/

# Option 2: Web application (when "frontend" + "backend" detected)
backend/
├── src/
│   ├── models/
│   ├── services/
│   └── api/
└── tests/

frontend/
├── src/
│   ├── components/
│   ├── pages/
│   └── services/
└── tests/

# Option 3: Mobile + API (when "iOS/Android" detected)
api/
└── [same as backend above]

ios/ or android/
└── [platform-specific structure]

Structure Decision: Option 1 (Single project) - Native desktop application with pkg/ for WebKit bindings

Phase 0: Outline & Research

  1. Extract unknowns from Technical Context above:

    • For each NEEDS CLARIFICATION → research task
    • For each dependency → best practices task
    • For each integration → patterns task
  2. Generate and dispatch research agents:

    For each unknown in Technical Context:
      Task: "Research {unknown} for {feature context}"
    For each technology choice:
      Task: "Find best practices for {tech} in {domain}"
    
  3. Consolidate findings in research.md using format:

    • Decision: [what was chosen]
    • Rationale: [why chosen]
    • Alternatives considered: [what else evaluated]

Output: research.md with all NEEDS CLARIFICATION resolved

Phase 1: Design & Contracts

Prerequisites: research.md complete

  1. Extract entities from feature spec → data-model.md:

    • Entity name, fields, relationships
    • Validation rules from requirements
    • State transitions if applicable
  2. Generate API contracts from functional requirements:

    • For each user action → endpoint
    • Use standard REST/GraphQL patterns
    • Output OpenAPI/GraphQL schema to /contracts/
  3. Generate contract tests from contracts:

    • One test file per endpoint
    • Assert request/response schemas
    • Tests must fail (no implementation yet)
  4. Extract test scenarios from user stories:

    • Each story → integration test scenario
    • Quickstart test = story validation steps
  5. Update agent file incrementally (O(1) operation):

    • Run /scripts/update-agent-context.sh [claude|gemini|copilot] for your AI assistant
    • If exists: Add only NEW tech from current plan
    • Preserve manual additions between markers
    • Update recent changes (keep last 3)
    • Keep under 150 lines for token efficiency
    • Output to repository root

Output: data-model.md, /contracts/*, failing tests, quickstart.md, agent-specific file

Phase 2: Task Planning Approach

This section describes what the /tasks command will do - DO NOT execute during /plan

Task Generation Strategy:

  • Load /templates/tasks-template.md as base
  • Generate tasks from WebKit bindings contract (webkit-bindings-api.yaml)
  • Create pkg/webkit package structure and CGO bridge tasks [P]
  • WebKit2GTK reference repository setup and analysis tasks
  • Contract tests for each WebKit API function [P]
  • Integration tests for browser features (navigation, zoom, shortcuts)
  • Migration tasks to remove Wails dependencies sequentially
  • Performance validation and data preservation verification tasks

Ordering Strategy:

  • TDD order: Contract tests before WebKit bindings implementation
  • Dependency order: CGO bridge → WebKit API → Browser integration → Wails removal
  • Parallel tasks: Independent WebKit functions, separate test files [P]
  • Sequential migration: Preserve existing functionality throughout transition

Estimated Output: 30-35 numbered, ordered tasks focusing on WebKit migration in tasks.md

IMPORTANT: This phase is executed by the /tasks command, NOT by /plan

Phase 3+: Future Implementation

These phases are beyond the scope of the /plan command

Phase 3: Task execution (/tasks command creates tasks.md)
Phase 4: Implementation (execute tasks.md following constitutional principles)
Phase 5: Validation (run tests, execute quickstart.md, performance validation)

Complexity Tracking

Fill ONLY if Constitution Check has violations that must be justified

Violation Why Needed Simpler Alternative Rejected Because
[e.g., 4th project] [current need] [why 3 projects insufficient]
[e.g., Repository pattern] [specific problem] [why direct DB access insufficient]

Progress Tracking

This checklist is updated during execution flow

Phase Status:

  • Phase 0: Research complete (/plan command)
  • Phase 1: Design complete (/plan command)
  • Phase 2: Task planning complete (/plan command - describe approach only)
  • Phase 3: Tasks generated (/tasks command)
  • Phase 4: Implementation complete
  • Phase 5: Validation passed

Gate Status:

  • Initial Constitution Check: PASS
  • Post-Design Constitution Check: PASS
  • All NEEDS CLARIFICATION resolved
  • Complexity deviations documented (none required)

Based on Constitution v2.1.1 - See /memory/constitution.md

source
1# Implementation Plan: Native WebKit Browser Backend
2
3**Branch**: `003-webkit2gtk-migration` | **Date**: 2025-01-21 | **Spec**: [spec.md](spec.md)
4**Input**: Feature specification from `/home/brice/dev/projects/dumb-browser/specs/003-webkit2gtk-migration/spec.md`
5
6## Execution Flow (/plan command scope)
7```
81. Load feature spec from Input path
9   → If not found: ERROR "No feature spec at {path}"
102. Fill Technical Context (scan for NEEDS CLARIFICATION)
11   → Detect Project Type from context (web=frontend+backend, mobile=app+api)
12   → Set Structure Decision based on project type
133. Evaluate Constitution Check section below
14   → If violations exist: Document in Complexity Tracking
15   → If no justification possible: ERROR "Simplify approach first"
16   → Update Progress Tracking: Initial Constitution Check
174. Execute Phase 0 → research.md
18   → If NEEDS CLARIFICATION remain: ERROR "Resolve unknowns"
195. Execute Phase 1 → contracts, data-model.md, quickstart.md, agent-specific template file (e.g., `CLAUDE.md` for Claude Code, `.github/copilot-instructions.md` for GitHub Copilot, or `GEMINI.md` for Gemini CLI).
206. Re-evaluate Constitution Check section
21   → If new violations: Refactor design, return to Phase 1
22   → Update Progress Tracking: Post-Design Constitution Check
237. Plan Phase 2 → Describe task generation approach (DO NOT create tasks.md)
248. STOP - Ready for /tasks command
25```
26
27**IMPORTANT**: The /plan command STOPS at step 7. Phases 2-4 are executed by other commands:
28- Phase 2: /tasks command creates tasks.md
29- Phase 3-4: Implementation execution (manual or via tools)
30
31## Summary
32Replace Wails framework with direct WebKit2GTK bindings to gain full control over browser engine capabilities, maintain all existing functionality while removing framework limitations, and create custom C Go bindings in a pkg/ package for potential future extraction.
33
34## Technical Context
35**Language/Version**: Go 1.25.1 + C bindings for WebKit2GTK  
36**Primary Dependencies**: WebKit2GTK, GTK3, CGO for C bindings  
37**Storage**: SQLite (maintain existing database schema and data)  
38**Testing**: Go testing + WebKit integration tests  
39**Target Platform**: Linux (Wayland/X11) - focus on GTK-based systems
40**Project Type**: single - native desktop application  
41**Performance Goals**: <500ms startup time, <100MB baseline memory, maintain existing performance  
42**Constraints**: Remove all Wails dependencies, preserve user data, maintain keyboard shortcuts and browser features  
43**Scale/Scope**: Single browser window, existing CLI functionality, WebKit2GTK reference clone for development
44
45## Constitution Check
46*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
47
48**Simplicity**:
49- Projects: 1 (single native browser application)
50- Using framework directly? ✅ (Direct WebKit2GTK, removing Wails wrapper)
51- Single data model? ✅ (Maintain existing SQLite schema)
52- Avoiding patterns? ✅ (Direct C bindings, no unnecessary abstraction layers)
53
54**Architecture**:
55- EVERY feature as library? ✅ (pkg/ package for WebKit bindings, reusable)
56- Libraries listed: pkg/webkit (WebKit2GTK Go bindings), existing internal packages
57- CLI per library: Maintain existing CLI, add webkit package testing commands
58- Library docs: llms.txt format planned for pkg/webkit
59
60**Testing (NON-NEGOTIABLE)**:
61- RED-GREEN-Refactor cycle enforced? ✅ (Contract tests for WebKit bindings first)
62- Git commits show tests before implementation? ✅ (Will create failing WebKit tests)
63- Order: Contract→Integration→E2E→Unit strictly followed? ✅ 
64- Real dependencies used? ✅ (Real WebKit2GTK, actual browser engine)
65- Integration tests for: WebKit bindings, browser functionality, keyboard shortcuts
66- FORBIDDEN: Implementation before test, skipping RED phase
67
68**Observability**:
69- Structured logging included? ✅ (Continue using slog)
70- Frontend logs → backend? ✅ (WebKit console logs to Go backend)
71- Error context sufficient? ✅ (WebKit error propagation to Go)
72
73**Versioning**:
74- Version number assigned? Next version after current (maintain semver)
75- BUILD increments on every change? ✅ 
76- Breaking changes handled? ✅ (Migration from Wails to native, preserve user data)
77
78## Project Structure
79
80### Documentation (this feature)
81```
82specs/[###-feature]/
83├── plan.md              # This file (/plan command output)
84├── research.md          # Phase 0 output (/plan command)
85├── data-model.md        # Phase 1 output (/plan command)
86├── quickstart.md        # Phase 1 output (/plan command)
87├── contracts/           # Phase 1 output (/plan command)
88└── tasks.md             # Phase 2 output (/tasks command - NOT created by /plan)
89```
90
91### Source Code (repository root)
92```
93# Option 1: Single project (DEFAULT)
94src/
95├── models/
96├── services/
97├── cli/
98└── lib/
99
100tests/
101├── contract/
102├── integration/
103└── unit/
104
105# Option 2: Web application (when "frontend" + "backend" detected)
106backend/
107├── src/
108│   ├── models/
109│   ├── services/
110│   └── api/
111└── tests/
112
113frontend/
114├── src/
115│   ├── components/
116│   ├── pages/
117│   └── services/
118└── tests/
119
120# Option 3: Mobile + API (when "iOS/Android" detected)
121api/
122└── [same as backend above]
123
124ios/ or android/
125└── [platform-specific structure]
126```
127
128**Structure Decision**: Option 1 (Single project) - Native desktop application with pkg/ for WebKit bindings
129
130## Phase 0: Outline & Research
1311. **Extract unknowns from Technical Context** above:
132   - For each NEEDS CLARIFICATION → research task
133   - For each dependency → best practices task
134   - For each integration → patterns task
135
1362. **Generate and dispatch research agents**:
137   ```
138   For each unknown in Technical Context:
139     Task: "Research {unknown} for {feature context}"
140   For each technology choice:
141     Task: "Find best practices for {tech} in {domain}"
142   ```
143
1443. **Consolidate findings** in `research.md` using format:
145   - Decision: [what was chosen]
146   - Rationale: [why chosen]
147   - Alternatives considered: [what else evaluated]
148
149**Output**: research.md with all NEEDS CLARIFICATION resolved
150
151## Phase 1: Design & Contracts
152*Prerequisites: research.md complete*
153
1541. **Extract entities from feature spec** → `data-model.md`:
155   - Entity name, fields, relationships
156   - Validation rules from requirements
157   - State transitions if applicable
158
1592. **Generate API contracts** from functional requirements:
160   - For each user action → endpoint
161   - Use standard REST/GraphQL patterns
162   - Output OpenAPI/GraphQL schema to `/contracts/`
163
1643. **Generate contract tests** from contracts:
165   - One test file per endpoint
166   - Assert request/response schemas
167   - Tests must fail (no implementation yet)
168
1694. **Extract test scenarios** from user stories:
170   - Each story → integration test scenario
171   - Quickstart test = story validation steps
172
1735. **Update agent file incrementally** (O(1) operation):
174   - Run `/scripts/update-agent-context.sh [claude|gemini|copilot]` for your AI assistant
175   - If exists: Add only NEW tech from current plan
176   - Preserve manual additions between markers
177   - Update recent changes (keep last 3)
178   - Keep under 150 lines for token efficiency
179   - Output to repository root
180
181**Output**: data-model.md, /contracts/*, failing tests, quickstart.md, agent-specific file
182
183## Phase 2: Task Planning Approach
184*This section describes what the /tasks command will do - DO NOT execute during /plan*
185
186**Task Generation Strategy**:
187- Load `/templates/tasks-template.md` as base
188- Generate tasks from WebKit bindings contract (webkit-bindings-api.yaml)
189- Create pkg/webkit package structure and CGO bridge tasks [P]
190- WebKit2GTK reference repository setup and analysis tasks
191- Contract tests for each WebKit API function [P]
192- Integration tests for browser features (navigation, zoom, shortcuts)
193- Migration tasks to remove Wails dependencies sequentially
194- Performance validation and data preservation verification tasks
195
196**Ordering Strategy**:
197- TDD order: Contract tests before WebKit bindings implementation
198- Dependency order: CGO bridge → WebKit API → Browser integration → Wails removal
199- Parallel tasks: Independent WebKit functions, separate test files [P]
200- Sequential migration: Preserve existing functionality throughout transition
201
202**Estimated Output**: 30-35 numbered, ordered tasks focusing on WebKit migration in tasks.md
203
204**IMPORTANT**: This phase is executed by the /tasks command, NOT by /plan
205
206## Phase 3+: Future Implementation
207*These phases are beyond the scope of the /plan command*
208
209**Phase 3**: Task execution (/tasks command creates tasks.md)  
210**Phase 4**: Implementation (execute tasks.md following constitutional principles)  
211**Phase 5**: Validation (run tests, execute quickstart.md, performance validation)
212
213## Complexity Tracking
214*Fill ONLY if Constitution Check has violations that must be justified*
215
216| Violation | Why Needed | Simpler Alternative Rejected Because |
217|-----------|------------|-------------------------------------|
218| [e.g., 4th project] | [current need] | [why 3 projects insufficient] |
219| [e.g., Repository pattern] | [specific problem] | [why direct DB access insufficient] |
220
221
222## Progress Tracking
223*This checklist is updated during execution flow*
224
225**Phase Status**:
226- [x] Phase 0: Research complete (/plan command)
227- [x] Phase 1: Design complete (/plan command)
228- [x] Phase 2: Task planning complete (/plan command - describe approach only)
229- [ ] Phase 3: Tasks generated (/tasks command)
230- [ ] Phase 4: Implementation complete
231- [ ] Phase 5: Validation passed
232
233**Gate Status**:
234- [x] Initial Constitution Check: PASS
235- [x] Post-Design Constitution Check: PASS  
236- [x] All NEEDS CLARIFICATION resolved
237- [x] Complexity deviations documented (none required)
238
239---
240*Based on Constitution v2.1.1 - See `/memory/constitution.md`*

Keyboard shortcuts

Single-key shortcuts are on. ctrl k and esc work whatever this says.

ctrl k :
go to a section, branch, tag, file or repository
?
this list
j k
move the row cursor down / up
enter
open the row under the cursor; on Files, a directory opens or closes in place
↑ ↓ ← → home end
in the file tree (focus on a row): previous / next row, close / open a directory or go to its parent / first entry, first / last row. They never open a file
l h
on Files: open a directory or a file / close a directory or go up to its parent, then to the parent page. Elsewhere: into the side panel (on a merge request, its files) / back to the content; there j k move between its controls
g g G
first / last row
/
filter the list; on Files, find a file anywhere in the repository (esc clears, enter opens the best match)
b
switch branch or tag
g s g f g c g b g m g i g r g a
tabs: summary, files, commits, branches & tags, merge requests, issues, releases, actions (when available)
g h
home
w
wide mode: use the whole width of the screen, or not (remembered)
y
copy a permalink pinned to the commit
d u x
diff: split / unified / collapse or expand all
e E
diff: the whole file in view / every file, with the lines the hunks hide
n
merge request: next note in the diff
esc
close a dialog, leave a field

Branches 8

Tags 42

↑↓ moveenter openesc close