docs: lowercase internal docs + migrate website docs to public-docs/ (#634)

* docs: rename to lowercase + drop leftover plans

Rename docs in docs/ to lowercase kebab-case for consistency and update
all references in CLAUDE.md, CONTRIBUTING.md, CHANGELOG.md,
packages/server/CLAUDE.md, and inter-doc links.

Drop two leftover design plan docs:
- docs/ATTACHMENT_BASED_REVIEW_CONTEXT_PLAN.md
- docs/plan-approval-normalization.md

* docs: drop stale uppercase entries from case-insensitive rename

* feat(website): power /docs from public-docs/ markdown tree

Move website docs out of TSX route components and into a root-level
public-docs/ directory of plain markdown files with frontmatter
(title, description, nav, order).

- Add packages/website/src/docs.ts loader using import.meta.glob with
  ?raw to compile the markdown into the bundle at build time.
- Replace the 9 hand-written docs/*.tsx routes with a single $.tsx
  catch-all that renders any slug via react-markdown.
- Drive the docs sidebar nav from frontmatter order/nav.
- Auto-discover docs routes in vite.config.ts so the sitemap stays in
  sync without manual edits.

* fix(website): bind dev server to 0.0.0.0 so port collisions trigger fallback

`host: "127.0.0.1"` (or unset) lets macOS coexist with another process
holding an IPv6 dual-stack `*:8082` socket, so Vite never sees
EADDRINUSE and silently binds alongside it. Forcing IPv4 wildcard
makes the conflict real, and Vite's default `strictPort: false`
falls through to the next free port.

* fix(website): restore docs page styling after markdown migration

Add a .docs-prose class that mirrors the styling the original
docs/*.tsx components hand-rolled (h1/h2/h3 sizes, paragraph/list
spacing, link colors, code blocks, callout-style blockquotes).

ReactMarkdown was emitting unstyled HTML because the previous
wrapper class only had inline-code rules — headings and code
blocks fell back to user-agent defaults.

docs/ATTACHMENT_BASED_REVIEW_CONTEXT_PLAN.md

@@ -1,158 +0,0 @@
-# Attachment-Based Review Context Plan
-
-## Goal
-
-Use structured attachments as the source of truth for review context during agent creation.
-
-This covers two related behaviors:
-
-1. Provider-facing context for the agent prompt
-2. Worktree checkout behavior when creating a worktree from a review item
-
-The design should stay compatible with future forge support such as GitLab.
-
-## Core Direction
-
-- Do not parse the prompt to discover issue/PR intent.
-- Do not introduce deeply nested transport objects for this flow.
-- Make the attachment itself the discriminated union.
-- Keep forge-specific checkout logic below the attachment layer.
-- Let each agent provider translate attachments into its own prompt/input format.
-
-## Initial Attachment Types
-
-Two initial structured attachment types:
-
-- `github_pr`
-- `github_issue`
-
-With separate MIME types:
-
-- `application/github-pr`
-- `application/github-issue`
-
-Proposed wire shape:
-
-```ts
-type AgentAttachment =
-  | {
-      type: "github_pr";
-      mimeType: "application/github-pr";
-      number: number;
-      title: string;
-      url: string;
-      body?: string | null;
-      baseRefName?: string | null;
-      headRefName?: string | null;
-    }
-  | {
-      type: "github_issue";
-      mimeType: "application/github-issue";
-      number: number;
-      title: string;
-      url: string;
-      body?: string | null;
-    };
-```
-
-## Backward Compatibility
-
-- Add new optional `attachments` fields; keep existing `images` fields.
-- Unknown attachment discriminators must be dropped during schema normalization instead of failing the full request.
-- Malformed attachment entries should also be ignored safely.
-- Old clients continue working because `attachments` is optional.
-- New clients can send `attachments` without breaking older flows that still rely on `images`.
-
-## Request-Level Changes
-
-Add optional `attachments` to:
-
-- `create_agent_request`
-- `send_agent_message_request`
-
-Existing `initialPrompt` remains plain user text.
-
-The selected GitHub PR/issue becomes a structured attachment instead of being injected into prompt text as the primary source of truth.
-
-## App Responsibilities
-
-When the user selects a GitHub item:
-
-- If it is a PR, create a `github_pr` attachment
-- If it is an issue, create a `github_issue` attachment
-- Include the attachment in the create-agent request
-
-The UI can still render friendly labels and previews from the same data.
-
-The app should stop treating PR/issue context as prompt-only metadata.
-
-## Worktree Creation Behavior
-
-During agent creation, if worktree creation is requested:
-
-- Inspect normalized attachments
-- If a `github_pr` attachment is present, use it to drive checkout for the worktree
-
-The important rule:
-
-- attachment type identifies the review object
-- server-side git logic decides how to check it out
-
-This keeps the attachment contract simple while allowing fork-safe implementation details.
-
-## Checkout Resolution
-
-The attachment itself should not encode the full checkout strategy.
-
-Instead, the server should resolve checkout from the `github_pr` attachment using forge-aware logic.
-
-Examples of possible implementation strategies:
-
-- `gh pr checkout`
-- `git fetch origin refs/pull/<number>/head:<local-branch>`
-- another GitHub-aware resolver if needed later
-
-This is intentionally a server implementation detail, not part of the attachment schema.
-
-## Provider Responsibilities
-
-Each provider adapter should receive normalized attachments and decide how to represent them for the model.
-
-Examples:
-
-- Claude: render attachment into text blocks
-- Codex: inject as blocks or text
-- OpenCode: send as file/resource-like input where appropriate
-- ACP: convert to resource/text forms as supported
-
-The session layer should not hardcode one translation strategy for all providers.
-
-## Suggested Implementation Order
-
-1. Add tolerant attachment schema and normalization in shared/server message handling.
-2. Thread `attachments` through app -> daemon client -> session layer.
-3. Update create-agent UI flows to emit `github_pr` / `github_issue` attachments from GitHub selection.
-4. Teach worktree creation to inspect attachments and special-case `github_pr`.
-5. Update provider adapters to translate attachments into provider-specific prompt/input forms.
-6. Optionally migrate image transport into the same attachment mechanism later.
-
-## Files Likely Involved
-
-- `packages/server/src/shared/messages.ts`
-- `packages/server/src/client/daemon-client.ts`
-- `packages/server/src/server/session.ts`
-- `packages/server/src/server/worktree-session.ts`
-- `packages/server/src/server/agent/agent-sdk-types.ts`
-- `packages/server/src/server/agent/providers/claude-agent.ts`
-- `packages/server/src/server/agent/providers/codex-app-server-agent.ts`
-- `packages/server/src/server/agent/providers/opencode-agent.ts`
-- `packages/server/src/server/agent/providers/acp-agent.ts`
-- `packages/app/src/screens/new-workspace-screen.tsx`
-- `packages/app/src/screens/agent/draft-agent-screen.tsx`
-- `packages/app/src/contexts/session-context.tsx`
-
-## Notes
-
-- The current image path can remain in place initially.
-- The plan intentionally keeps checkout concerns separate from provider prompt translation.
-- Future forge support should add new attachment discriminators rather than expanding GitHub-only nested fields.

docs/design-system.md

@@ -1,4 +1,4 @@
-# DESIGN-SYSTEM.md
+# Design system
 
 Tokens — every color, font size, weight, spacing step, radius, icon size — live in `packages/app/src/styles/theme.ts`.
 

docs/design.md

@@ -17,7 +17,7 @@ Before designing anything new, understand what exists:
 
 - Where does similar functionality live?
 - What patterns does the codebase already use?
-- What layers exist? (See [ARCHITECTURE.md](./ARCHITECTURE.md))
+- What layers exist? (See [architecture.md](./architecture.md))
 - What types and data shapes are already defined?
 
 New features rarely mean only new code. Usually they require modifying existing interfaces, extending existing types, or refactoring to accommodate the new functionality. Identify what needs to change, not just what needs to be added.
@@ -38,7 +38,7 @@ If you can't define verification, you don't understand the feature well enough y
 
 - What types are needed?
 - Use discriminated unions — make impossible states impossible
-- One canonical type per concept (see [CODING_STANDARDS.md](./CODING_STANDARDS.md))
+- One canonical type per concept (see [coding-standards.md](./coding-standards.md))
 
 ### Layers
 

docs/mobile-testing.md

@@ -261,4 +261,4 @@ xcrun simctl ui booted appearance dark     # set dark
 xcrun simctl ui booted appearance light    # set light
 ```
 
-Expo dev server logs are in the tmux pane running `npm run dev`. Daemon logs are at `$PASEO_HOME/daemon.log` (see [DEVELOPMENT.md](DEVELOPMENT.md)).
+Expo dev server logs are in the tmux pane running `npm run dev`. Daemon logs are at `$PASEO_HOME/daemon.log` (see [development.md](development.md)).

docs/plan-approval-normalization.md

@@ -1,68 +0,0 @@
-# Plan Approval Normalization
-
-## Goal
-
-Normalize plan approval across providers so the UI renders one consistent plan approval card and action row, while each provider keeps its own execution quirks behind the session permission interface.
-
-## Compatibility Constraints
-
-- Older clients must remain compatible with newer daemons.
-- All new wire fields must be optional.
-- Existing plan permissions without action metadata must still render and work.
-- Existing question permissions must keep their current behavior.
-
-## Design
-
-### Shared abstraction
-
-Add optional permission action definitions to the shared permission request/response types.
-
-- Permission requests may include `actions`.
-- Permission responses may include `selectedActionId`.
-- `kind: "plan"` remains the normalized concept for plan approval.
-- The UI renders actions from the permission request instead of hardcoding provider-specific buttons.
-
-### Claude
-
-Keep Claude's plan permission flow, but enrich it with explicit action definitions.
-
-- Always expose `Reject`.
-- Always expose `Implement`.
-- If the agent entered plan mode from a more permissive mode like `bypassPermissions`, also expose `Implement with <previous mode>`.
-- Resolve the selected action entirely inside `respondToPermission()`.
-
-### Codex
-
-Synthesize a normalized `kind: "plan"` permission after a Codex plan-mode turn completes with a plan result.
-
-- Emit a plan permission with `Reject` and `Implement` actions.
-- On `Implement`, disable `plan_mode`, disable `fast_mode`, and automatically start a follow-up implementation turn.
-- On `Reject`, resolve without starting a follow-up turn.
-- Keep the implementation prompt and state transitions inside the Codex provider.
-
-### Manager and state sync
-
-After permission resolution, refresh provider-derived state so the UI sees internal mode/feature changes without knowing provider quirks.
-
-- Refresh current mode
-- Refresh pending permissions
-- Refresh runtime info
-- Refresh features
-- Persist refreshed state
-
-### UI
-
-Render plan permissions through the existing plan card, but generate buttons from normalized permission actions.
-
-- If `actions` are absent, fall back to legacy buttons.
-- Plan cards should use `Implement` as the default primary label.
-- Do not add provider-specific rendering branches.
-
-## Verification
-
-1. Shared schema/type tests for optional `actions` and `selectedActionId`
-2. App tests for generic plan-action rendering
-3. Claude tests for third action when resuming from a more permissive mode
-4. Codex tests for synthetic plan approval and automatic implementation follow-up
-5. Manager tests for post-permission state refresh
-6. `npm run typecheck`