mirror of
https://github.com/stablyai/orca.git
synced 2026-10-20 00:03:45 +00:00
NeilandOrca
057a81493a
* fix(sidebar): guard every worktree sort against undefined displayName (crash 99657ab1) Worktree.displayName is typed non-optional but arrives undefined at runtime for persisted/discovered worktrees (crash 99657ab1). PR #8683 fixed the kanban board; this extends the same guard to the five other sort sites that share those worktree objects — including the Cmd+J switcher (order-empty-query-worktrees) — via one shared compareWorktreeDisplayName helper in lib/. Behavior-neutral when names are present; a missing name now sorts as '' instead of throwing. Co-authored-by: Orca <help@stably.ai> * docs(agents): add over-commenting anti-pattern example to the comment rule Anchors the existing 'document the why, briefly' rule with a concrete before/after (the worktree-displayName guard) so agents stop dumping the crash id, mechanism, file location, and every call site into a comment. Co-authored-by: Orca <help@stably.ai> --------- Co-authored-by: Orca <help@stably.ai>
71 lines
5.2 KiB
Markdown
71 lines
5.2 KiB
Markdown
# AGENTS.md
|
|
|
|
## Design System
|
|
|
|
All UI work — layout, color, typography, spacing, component selection, UX behavior — must follow [`docs/STYLEGUIDE.md`](./docs/STYLEGUIDE.md). Use the tokens defined in `src/renderer/src/assets/main.css` (the canonical source) and the shadcn primitives in `src/renderer/src/components/ui/`. Don't invent new color values, font sizes, or shadow tiers when a documented one already covers the role. When STYLEGUIDE.md is silent, follow the resolution order in its final section.
|
|
|
|
## Code Comments: Document the "Why", Briefly
|
|
|
|
When writing or modifying code driven by a design doc or non-obvious constraint, add a comment explaining **why** the code behaves the way it does.
|
|
|
|
Keep comments short — one or two lines. Capture only the non-obvious reason (safety constraint, compatibility shim, design-doc rule). Don't restate what the code does, narrate the mechanism, cite design-doc sections verbatim, or explain adjacent API choices unless they're the point.
|
|
|
|
The comment's audience is the next person reading that line, not a PR description. If a comment lists call sites, recounts the crash/history, or re-describes the code below it, cut it to the one non-obvious fact:
|
|
|
|
```ts
|
|
// 🚫 Over-explained — narrates the crash, the mechanism, where the helper lives, and every caller:
|
|
// Why: Worktree.displayName is typed non-optional, but persisted/discovered worktrees have reached
|
|
// the UI with an undefined name (crash 99657ab1), which made a bare displayName.localeCompare(...)
|
|
// throw a TypeError and take down whatever was sorting them. Lives in lib so every worktree sort
|
|
// site (sidebar board, Cmd+J switcher, right-sidebar, add-repo telemetry) shares one guard.
|
|
|
|
// ✅ Just the non-obvious constraint:
|
|
// Why: displayName is typed non-optional but arrives undefined at runtime (crash 99657ab1); coalesce so it can't throw.
|
|
```
|
|
|
|
## Lint Rules: Do Not Disable Max Lines
|
|
|
|
Never add a `max-lines` disable (`eslint-disable max-lines`, `oxlint-disable max-lines`, or line-specific variants), and never add a per-file `max-lines` bump in `mobile/.oxlintrc.json`.
|
|
|
|
## File and Module Naming
|
|
|
|
Never use vague names like `helpers`, `utils`, `common`, `misc`, or `shared-stuff` for files, folders, or modules. They carry zero info and tend to become dumping grounds. Name files after what they _actually_ contain — prefer the concrete domain concept (e.g. `tab-group-state.ts`, `terminal-orphan-cleanup.ts`) over the generic role (`tabs-helpers.ts`, `terminal-utils.ts`). If you find yourself reaching for `helpers`, the file probably has more than one responsibility and should be split, or there's a better name hiding in the code that describes what the functions operate on.
|
|
|
|
## Worktree Safety
|
|
|
|
Always use the primary working directory (the worktree) for all file reads and edits. Never follow absolute paths from subagent results that point to the main repo.
|
|
|
|
## Cross-Platform Support
|
|
|
|
Orca targets macOS, Linux, and Windows. Keep all platform-dependent behavior behind runtime checks:
|
|
|
|
- **Keyboard shortcuts**: Never hardcode `e.metaKey`. Use a platform check (`navigator.userAgent.includes('Mac')`) to pick `metaKey` on Mac and `ctrlKey` on Linux/Windows. Electron menu accelerators should use `CmdOrCtrl`.
|
|
- **Shortcut labels in UI**: Display `⌘` / `⇧` on Mac and `Ctrl+` / `Shift+` on other platforms.
|
|
- **File paths**: Use `path.join` or Electron/Node path utilities — never assume `/` or `\`.
|
|
|
|
## SSH Use Case
|
|
|
|
All changes must consider the SSH use case. Don't assume local-only execution.
|
|
|
|
## Git Binary Compatibility
|
|
|
|
Orca runs the user's Git binary on native, WSL, and SSH hosts, which may all have different versions. Treat Git 2.25 as the core-workflow baseline and follow [`docs/reference/git-compatibility.md`](./docs/reference/git-compatibility.md).
|
|
|
|
When adding or changing a Git command:
|
|
|
|
- Check when every subcommand and option was introduced. For newer behavior, keep a baseline-compatible fallback or degrade safely.
|
|
- Use `GitCapabilityCache` with a narrow unsupported-error predicate so recurring operations do not retry a known-invalid command. Do not rely only on `git --version`; wrappers such as `simple-git` do not remove host-version differences.
|
|
- Scope capability state to the host that executes Git: native, WSL distro, SSH provider, or relay connection. Cover the first fallback, later cached calls, concurrent probes, and relevant host isolation in tests.
|
|
- Keep the real-binary compatibility contract in PR CI current. When adopting a newer Git feature, add its version boundary so the preferred command and fallback both run against representative Git releases.
|
|
- Preserve commands that begin with global Git options such as `-c` before the subcommand, including auto-maintenance suppression used by worktree-create fetches.
|
|
|
|
## Git Provider Compatibility
|
|
|
|
Source-control and review changes must consider GitLab and other supported git providers, not only GitHub. Keep provider-specific behavior behind explicit checks, and avoid GitHub-only naming for generic review concepts.
|
|
|
|
## GitHub CLI Usage
|
|
|
|
Be mindful of the user's `gh` CLI API rate limit — batch requests where possible and avoid unnecessary calls. All code, commands, and scripts must be compatible with macOS, Linux, and Windows.
|
|
|
|
## Type Declarations: Prefer `.ts` Over `.d.ts`
|