jpmschweitzer/clide
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

drop leading zeros from all D/Q/R/T IDs

Browse Source 
pql 1.2.0 changed its record format to drop leading zeros. All
262 references across 18 files renumbered (D-001→D-1, T-043→T-43,
etc.). pql-plan.json export updated as the git source of truth
for the planning database. DB rebuilt via pql plan import.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
jpmschweitzer
2026-04-23 12:16:52 +02:00
co-authored by Claude Opus 4.6
parent 9689fe65c1
commit 2235cc4c19
18 changed files with 3016 additions and 257 deletions
Download Patch File Download Diff File Expand all files Collapse all files
decisions/questions-process.md
+10 -10
View File
@@ -7,37 +7,37 @@ Tooling-domain questions currently live here too. Split into
---
### Q-015: Editor tab — full LSP vs tree-sitter-only highlight
### Q-15: Editor tab — full LSP vs tree-sitter-only highlight
- **Status:** Open
- **Question:** Tier 2's editor tab: do we integrate a full LSP story (analyzer server + hovers + completions + diagnostics) or ship tree-sitter-only syntax highlighting and defer LSP to Tier 6?
- **Context:** Full LSP is a large subsystem; tree-sitter is a weekend. User is a heavy LSP user in other IDEs — missing it hurts. CLAUDE.md flags this as "decide during Tier 2."
- **Source:** CLAUDE.md "Open questions" footer.
### Q-016: `tree-sitter-dart` grammar maintenance
### Q-16: `tree-sitter-dart` grammar maintenance
- **Status:** Open
- **Question:** `UserNobody14/tree-sitter-dart` is archived. `nielsenko/tree-sitter-dart` is the maintained fork. Do we pin `nielsenko/`, mirror it in-repo, or lean on the Dart analyzer's own semantic output and skip tree-sitter for Dart?
- **Context:** If tree-sitter is the Tier-2 answer ([Q-015](#q-015-editor-tab-full-lsp-vs-tree-sitter-only)), grammar sourcing matters.
- **Context:** If tree-sitter is the Tier-2 answer ([Q-15](#q-15-editor-tab-full-lsp-vs-tree-sitter-only)), grammar sourcing matters.
- **Source:** 2026-04-21 planning.
### Q-017: Icon set growth
### Q-17: Icon set growth
- **Status:** Open
- **Question:** Hand-drawn `CustomPainter` catalogue (total control, pixel-perfect on every theme, slow to grow) vs SVG + parser (faster to grow, one more dep, theming is harder)?
- **Context:** We rejected Nerd-font glyphs ([R-006](rejected.md#r-006-nerd-font-glyph-icons)); something has to fill the gap.
- **Context:** We rejected Nerd-font glyphs ([R-6](rejected.md#r-6-nerd-font-glyph-icons)); something has to fill the gap.
- **Source:** 2026-04-21 planning.
### Q-018: Theme hot-reload in release builds
### Q-18: Theme hot-reload in release builds
- **Status:** Open
- **Question:** The theme picker supports live-reloading a YAML during development. Does the same path stay open in release builds (user tweaks `~/.config/clide/themes/foo.yaml` and the app re-reads on focus) or is release-build theming restricted to built-in + settings-UI-installed themes?
- **Context:** Hot-reload is powerful for theme authoring but opens a file-watch + re-parse path in release code.
- **Source:** 2026-04-21 planning.
### Q-019: (withdrawn)
### Q-19: (withdrawn)
- **Status:** Resolved → n/a
- **Note:** Earlier floated as "ticket markdown mirror vs SQLite" — no longer a split question. Markdown mirror is tracked in [Q-022](questions-architecture.md#q-022-ticket-persistence-strategy); SQLite is the current stopgap per [D-040](process.md#d-040-python-stopgap-under-toolsscriptsplan).
- **Note:** Earlier floated as "ticket markdown mirror vs SQLite" — no longer a split question. Markdown mirror is tracked in [Q-22](questions-architecture.md#q-22-ticket-persistence-strategy); SQLite is the current stopgap per [D-40](process.md#d-40-python-stopgap-under-toolsscriptsplan).
### Q-020: Kernel DB service — namespaced SQL access?
### Q-20: Kernel DB service — namespaced SQL access?
- **Status:** Open
- **Question:** Do extensions get namespaced SQL access to `.clide/clide.db` (tables prefixed `ext_<id>_…`) or stay on the `kernel.settings` key/value facade? Admission-level question ([D-012](architecture.md#d-012-kernel-admission-rule)).
- **Question:** Do extensions get namespaced SQL access to `.clide/clide.db` (tables prefixed `ext_<id>_…`) or stay on the `kernel.settings` key/value facade? Admission-level question ([D-12](architecture.md#d-12-kernel-admission-rule)).
- **Context:** Some extensions (tickets, canvas, graph) naturally want relational storage. K/V gets awkward fast.
- **Source:** 2026-04-21 planning.