jpmschweitzerandClaude Opus 4.8
526daed237
Fixes 11 distinct inline anchor slugs that drifted from the generated canonical form: em-dash titles render `--` (single-hyphen links were stale), plus several truncated/old slugs (D-5, D-10, D-21, D-39, D-40, D-43, D-68, Q-1, Q-32, Q-33). pql resolves cross-refs by ID so these were never "broken" to the tooling, but they'd fail GitHub markdown anchor navigation. Verified: every inline anchor now matches the README index; pql decisions sync reports 0 broken refs. Does NOT touch the separate stale-path class (flat `questions-*.md` / `rejected.md` naming from before the DQR subdir split) — surfaced for a follow-up. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
3.2 KiB
3.2 KiB
Rejected — Architecture
Alternatives considered and rejected, with rationale preserved for future reference.
R-2: Go sidecar
- Rejected: 2026-04-20 (was ADR 0002; superseded by D-5)
- Reason: The ADR picked Go on two premises — (a) the heavy work belongs in a language separate from the UI layer, and (b) pql is Go so muscle memory transfers. Both broke on reassessment. The sidecar stripped of PTY is I/O-bound glue that
dart:iocovers cleanly (unix sockets, JSON-lines framing, process tables, shell-outs). The real axis was separate process vs shared language, not Go vs Rust, and separate-process is what matters (session persistence needs the daemon to outlive the app), not language. PTY is the one place Dart is genuinely weak — Dart's multi-threaded VM can't safelyfork()— and that single constraint forces a native helper regardless, independent of whether the rest of the core is Dart. Once a small native helper is accepted, the question "does everything else need to be in that same native language" answers itself: no. Go sidecar directory dissolved;ptyc(C, PTY-only, pql-peer) is the surviving native supporter tool. - Cross-reference: D-5
R-3: MaterialApp root
- Rejected: 2026-04-21
- Reason: Dragged in Material theming, default icons, and platform chrome that fought the custom three-tier theme pipeline (D-9). Every bundled theme had to override Material defaults to look like clide; the overrides were visible in widget tests as "why is this
ElevatedButtoncolored this way." - Cross-reference: D-7
R-7: CupertinoApp root
- Rejected: 2026-04-21
- Reason: iOS-opinionated; wrong shell for a Linux-primary desktop IDE. Same theming-collision problem as R-3.
- Cross-reference: D-7
R-8: Riverpod / Provider / BLoC for state
- Rejected: 2026-04-21
- Reason: Violates D-31.
ChangeNotifier+ListenableBuildership in the SDK, fake trivially, and cover the state model we need. The ergonomic wins of Riverpod / Provider don't clear the "new dependency" bar at clide's scale. - Cross-reference: D-10
R-12: MaterialApp wrapper from design handoff
- Rejected: 2026-04-22
- Reason: The design handoff delivers theme files as
MaterialApp/ThemeDataDart classes. This is the delivery format of claude.ai/design, not a design intent. Adopting Material's widget system would contradict D-7 (bare WidgetsApp, no Material/Cupertino). We translate the palette tokens and syntax roles into our existing YAML +SurfaceTokenspipeline. - Cross-reference: D-43