diff --git a/.pql/changelog/tickets/2026-06.sql b/.pql/changelog/tickets/2026-06.sql index 2d12d287..95ae141e 100644 --- a/.pql/changelog/tickets/2026-06.sql +++ b/.pql/changelog/tickets/2026-06.sql @@ -3385,3 +3385,18 @@ STATUS INDICATOR (live tick reuse): the bundled edits card carries ONE header st So the collapsed card''s indicator animates spinner<->check as the run grows, rather than showing a static tick. Each individual edit keeps its own tick in the expanded list (unchanged); this is the aggregate indicator on the holder header/ticker. Mirror the same treatment for the existing "# steps" activity card if it doesn''t already do this. DONE 2026-06-09 (commit). coalesceEditRuns folds consecutive same-file edits into one ''# edits'' ClideHolderCard; aggregate live status via new ClideStatusIndicator (running/success/error) + ClideSpinner (logo-mark, 3D Y rotation, reduced-motion aware), shared with the activity card. Per user: spinner is a self-contained component (not built on ConversationCard''s mark) with an AnimatedSwitcher seam for a richer spinner→check transition later. Tests: activity_cluster_test (coalesce), conversation_view_test (edits card), clide_status_indicator_test.', 'done', 'medium', NULL, NULL, NULL, '2026-06-09 15:43:58', '2026-06-09 16:34:46', NULL, '7d71f2e8bc6632dcc096d91d748d0cde', 1) ON CONFLICT(id) DO UPDATE SET type=excluded.type, parent_id=excluded.parent_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > tickets.updated_at OR (excluded.updated_at = tickets.updated_at AND excluded.hash > tickets.hash); +INSERT INTO tickets (id, type, parent_id, title, description, status, priority, assigned_to, team, decision_ref, created_at, updated_at, deleted_at, hash, canonical_version) VALUES ('T-299', 'task', NULL, 'Automate supply-chain checks in CI (osv-scanner + native SHA verification)', 'Salvaged from gemini-report.md (external code-analysis). Today supply-chain checks are MANUAL — Makefile ''security'' target just prints ''Dart advisories reviewed manually before pubspec.yaml bumps''; there is no automated vuln scan or native-artifact integrity check. Automate both to harden the chain as we move to automated CI, complementing the existing prefer-zero-deps / exact-pin / licenses.yaml discipline (D-31, D-61, D-63). + +1. Automate Dart dependency vulnerability scanning: + - Run an automated scanner (e.g. Google osv-scanner) against pubspec.lock on every push/PR. + - Wire into the CI workflow and/or the Makefile ''security'' target so it runs in push-check. + - Fail the gate on known advisories; keep it quiet/zero-noise otherwise. + +2. Automate native/vendored dependency SHA256 verification (D-63): + - CI step / pre-push script that parses assets/licenses.yaml (+ relevant BUILD.md) for declared native artifacts (dugite-native, libtree-sitter.so), and verifies the SHA256 of the vendored binaries against the committed/expected hashes. + - Guards against silent corruption or tampering of vendored binaries; ensures they match the audited sources. + +Notes: +- Both should be low-noise, runnable locally and in CI (candidate home: ci/security.sh + a Makefile target, surfaced via push-check). +- Scope is automation only — the manual review discipline already exists; this makes it enforced rather than convention. +- Source report (gemini-report.md) is being removed from the repo once this ticket captures its only actionable content.', 'backlog', 'medium', NULL, NULL, NULL, '2026-06-09 16:42:47', '2026-06-09 16:42:47', NULL, '3a10dc76cf86083d128080c29a41ac18', 1) ON CONFLICT(id) DO UPDATE SET type=excluded.type, parent_id=excluded.parent_id, title=excluded.title, description=excluded.description, status=excluded.status, priority=excluded.priority, assigned_to=excluded.assigned_to, team=excluded.team, decision_ref=excluded.decision_ref, updated_at=excluded.updated_at, deleted_at=excluded.deleted_at, hash=excluded.hash, canonical_version=excluded.canonical_version WHERE excluded.updated_at > tickets.updated_at OR (excluded.updated_at = tickets.updated_at AND excluded.hash > tickets.hash); diff --git a/gemini-report.md b/gemini-report.md deleted file mode 100644 index 51148d3e..00000000 --- a/gemini-report.md +++ /dev/null @@ -1,83 +0,0 @@ -# Gemini Code Analysis Report - -## Summary of Findings - -The `clide` project is a Flutter-based IDE characterized by exceptionally high standards for code quality, architectural discipline, and security. The design and engineering process is governed by a detailed set of decision records, revealing a mature and deliberate approach to software development. - -**Directory Structure & Architecture:** -The architecture is a well-documented, monolithic Flutter package that has evolved through deliberate, recorded decisions. Key architectural characteristics include: -- A modular structure (`kernel`, `src`, `widgets`, `extension`). -- An in-process IPC server that replaced an earlier two-process daemon model (`D-56`). -- A "CLI-first" agent interaction model, later expanded to a dual surface with a secondary MCP server for broader compatibility (`D-1`, `D-68`). -- A decision to render Claude's output with native Flutter widgets, moving away from terminal emulation for the primary interface (`D-75`). -- A commitment to owning the rendering stack, with custom-built UI primitives instead of relying on Material or Cupertino (`D-7`, `D-88`). - -**Code Quality & Best Practices:** -Quality is a core, non-negotiable principle, enforced by multiple layers of process and automation documented in the governance records: -- **Comprehensive Testing (`testing.md`):** A seven-layer testing pyramid, including unit, widget, golden, accessibility, integration, E2E, and startup smoke tests (`D-23`). -- **High Coverage Standard:** A non-negotiable 95% test coverage floor, ratcheted up over time (`D-66`). -- **Accessibility as a Core Contract (`accessibility.md`):** Accessibility is a "Tier-0" requirement, not an afterthought. This includes automated WCAG-AA contrast checks, guaranteed semantics on all primitives, and i18n support from day one (`D-20`, `D-22`). -- **Formal Governance (`governance/`):** All significant architectural and process decisions are documented in a formal Q&D (Questions & Decisions) system, ensuring clarity and accountability. - -**Security & Privacy:** -The security posture is proactive and deeply embedded in the project's architecture and philosophy. -- **Explicit "No Telemetry" Policy (`D-64`):** A foundational, architectural commitment to not collect any user data, phone home, or perform unsolicited network requests. -- **Sandboxed Extensions (`D-16`):** A clear security boundary for third-party code, which will run in a sandboxed Lua environment, in contrast to bundled Dart extensions. -- **Hardened Supply Chain (`tooling.md`):** A "prefer-zero-deps" philosophy, exact version pinning, and a rigorous vetting checklist for all dependencies (`D-31`, `D-61`). -- **Path and Toolchain Safety:** Strong, multi-layered protection against path traversal attacks (`D-80`), and a hardened toolchain that avoids executing untrusted binaries (`D-5`, `D-59`). - -- **Area for Improvement:** - - **Dependency Scanning:** The project relies on a manual review process for third-party dependency vulnerabilities. While the minimal dependency surface makes this manageable, automating this check in CI would further strengthen the supply chain. - -**Conclusion:** -This is a high-quality codebase built by an exceptionally disciplined team. The `governance/decisions` records show a project where every major decision is deliberate, documented, and aligned with core principles of quality, security, and user trust. It serves as a model for mature software engineering practices. - -## Relevant Locations - -* **`/var/mnt/data/projects/clide/governance/decisions/`**: The heart of the project's architectural and process knowledge. This directory contains detailed, versioned decision records that explain the *why* behind every significant aspect of the codebase, from testing strategy to security policies. It is the most important location for understanding the project's high level of engineering discipline. -* **`/var/mnt/data/projects/clide/docs/architecture.md`**: This file, itself a decision record, provides a high-level blueprint of the project's design, process model, and key directories. -* **`/var/mnt/data/projects/clide/pubspec.yaml`**: Defines the project as a Flutter application and specifies its minimal, exact-pinned dependencies. The `coverage_floor: 95` entry is a key indicator of the project's high quality standards, enforced by CI. -* **`/var/mnt/data/projects/clide/Makefile`**: The entry point for development and CI processes, defining reproducible targets for testing, building, and security checks. -* **`/var/mnt/data/projects/clide/lib/src/files/path_safety.dart`**: Implements critical security controls to prevent path traversal and symlink-based attacks, demonstrating a proactive security posture. -* **`/var/mnt/data/projects/clide/lib/kernel/src/toolchain_paths.dart`**: Implements toolchain hardening to prevent the execution of untrusted binaries from the workspace. - -## Recommendations for Improvement - -While the project demonstrates exceptionally high standards, the following suggestions could further enhance its robustness as you transition to fully automated build CI: - -1. **Automate Dart Dependency Scanning:** - * **Action:** Integrate an automated vulnerability scanner into the CI pipeline (e.g., in `.gitea/workflows/test.yml`). - * **Implementation:** Tools like Google's `osv-scanner` can be run against the `pubspec.lock` file on every PR or push. This would provide a continuous, automated check for known vulnerabilities in the project's Dart/Flutter dependency tree. - -2. **Automate Native/Vendored Dependency Verification:** - * **Action:** Automate the "SHA expectation" and integrity checks for native dependencies (`D-63`). - * **Implementation:** Create a CI step or pre-push script (e.g., `ci/security.sh` or a target in the `Makefile`) that: - 1. Parses `assets/licenses.yaml` and the various `BUILD.md` files. - 2. Fetches the specified native source artifacts (such as `dugite-native` or `libtree-sitter.so`) from their declared URLs or git commit SHAs. - 3. Verifies the SHA256 hash of the fetched artifacts against the committed hashes. - * This ensures that the vendored binaries in the repository correspond exactly to the audited source code, preventing silent corruption or tampering. - -These automated checks would complement the existing rigorous processes and provide a stronger security and supply-chain posture with minimal maintenance overhead as the project moves toward a fully automated CI model. - -## Exploration Trace - -### Initial Scan -* Read `pubspec.yaml` to understand the project's purpose, dependencies, and high-level quality metrics. -* Read `analysis_options.yaml` to understand the project's linting and formatting rules. -* Read `docs/architecture.md` to get a high-level overview of the project's design, process model, and key directories. -* Read `ci/security.sh` to begin investigating the automated security checks. -* Read `Makefile` to find the implementation of the `security` target called by the CI script. -* Read `assets/licenses.yaml` to investigate how native dependencies are managed and if integrity checks are in place. -* Read `lib/kernel/src/toolchain_paths.dart` to analyze the implementation of the secure `git` executable resolution. -* Used `list_directory` on `lib/src/files/` to locate the file responsible for path safety. -* Read `lib/src/files/path_safety.dart` to analyze the implementation of path traversal and symlink attack prevention. - -### Governance Review -* Listed files within `governance/decisions/`. -* Read `governance/decisions/accessibility.md` -* Read `governance/decisions/architecture.md` -* Read `governance/decisions/design.md` -* Read `governance/decisions/extensions.md` -* Read `governance/decisions/process.md` -* Read `governance/decisions/testing.md` -* Read `governance/decisions/tooling.md`