{"owner":"YishenTu","repo":"claudian","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# AGENTS.md\n\n## Project\n\nClaudian is an Obsidian plugin that embeds provider-backed coding agents in a sidebar and inline-edit flow. Claude is the default provider. Codex, Grok, OpenCode, and Pi are optional providers that plug into the same conversation model through `Conversation.providerId` and opaque provider-owned `providerState`.\n\nDo not assume provider parity. Check each provider's `capabilities.ts`, `registration.ts`, and UI config before wiring shared behavior.\n\n## Scope Guides\n\n- Before editing a scoped area, read its nearest scoped guide:\n  - `src/app/AGENTS.md`\n  - `src/core/AGENTS.md`\n  - `src/features/chat/AGENTS.md`\n  - `src/providers/claude/AGENTS.md`\n  - `src/providers/codex/AGENTS.md`\n  - `src/providers/grok/AGENTS.md`\n  - `src/providers/opencode/AGENTS.md`\n  - `src/providers/pi/AGENTS.md`\n  - `src/style/AGENTS.md`\n\n## AGENTS.md Maintenance\n\n- AGENTS.md is execution context for agents, not general documentation. Keep only repository- or scope-specific information that a capable agent would not reliably know; every statement must change implementation, review, or verification behavior.\n- Keep repository-wide rules here; put local ownership, dependencies, invariants, failure modes, verification, and active decisions in the narrowest scoped guide that governs them.\n- Do not duplicate inherited guidance or silently contradict it. State a necessary local exception and its rationale explicitly.\n- Omit tours, ordinary implementation details, temporary status, and general engineering advice.\n- Record a decision only when it is active, surprising from the code, expensive to reverse, and reflects a real tradeoff. State the decision, rationale, and any concrete reconsideration condition; use Git history as the archive.\n- `CLAUDE.md` files should import the nearest `AGENTS.md`; do not duplicate shared guidance there.\n\n## Commands\n\n```bash\nnpm run dev\nnpm run build\nnpm run typecheck\nnpm run lint\nnpm run lint:fix\nnpm run test\nnpm run test:watch\nnpm run test:coverage\n```\n\nThe default full check is:\n\n```bash\nnpm run typecheck && npm run lint && npm run test && npm run build\n```\n\nTests mirror `src/` under `tests/unit/` and `tests/integration/`.\n\n## Architecture\n\nScoped guides define the source of truth and allowed mutators for state in their area.\n\n| Area | Responsibility |\n| --- | --- |\n| `src/main.ts` | Plugin lifecycle and concrete application composition |\n| `src/app/` | Application conversation, settings, provider-host, and storage services |\n| `src/core/` | Provider-neutral runtime, registry, storage, tool, and type contracts |\n| `src/providers/acp/` | Shared ACP transport, interaction, and session primitives without provider policy |\n| `src/providers/*/` | Provider adaptors, provider-owned runtime protocol, history, storage, settings, and UI |\n| `src/features/chat/` | Sidebar chat orchestration against provider-neutral contracts |\n| `src/features/inline-edit/` | Inline edit modal and provider-backed edit services |\n| `src/features/settings/` | Shared settings shell and provider tab assembly |\n| `src/shared/` | Reusable UI components |\n| `src/style/` | Modular CSS built into `styles.css` |\n\n### Dependency Direction\n\nIn the rules below, `A -> B` means `A` may import or call `B`:\n\n```text\ncomposition root (`src/main.ts`) -> app services + features + provider registrations + core\napp services -> core contracts\nfeatures -> FeatureHost + core contracts + shared UI\nproviders -> ProviderHost + core contracts + shared provider and UI primitives\n```\n\n- `core/` must not import feature code, app composition, or provider implementations.\n- Feature code must not import provider implementations. Resolve provider behavior through core registries and contracts.\n- Provider runtime and protocol code must not import chat views, feature controllers, or other feature orchestration.\n- Existing Claude compatibility re-exports that point into `src/app/` are migration seams, not an allowed general dependency direction. Do not add new provider-to-app imports; move shared contracts into `core/` when touching those seams materially.\n- `src/providers/acp/` may contain protocol primitives shared by ACP providers. Provider-specific launch policy, extensions, normalization, history, and state remain in the owning provider.\n- If a dependency does not fit these directions, introduce or extend an explicit contract at the owning boundary instead of reaching across layers.\n\n### Cross-Layer Ownership\n\n- `src/main.ts` owns plugin lifecycle and wiring; it does not become the home for feature or provider behavior.\n- `src/app/` owns application-scoped repositories, settings transactions, host adapters, and persistence coordination. See its scoped guide for exact state authority.\n- `src/features/*/` owns user-facing orchestration and presentation state, not provider-native processes or storage formats.\n- `src/providers/*/` owns native protocol, process, session, transcript, settings, and provider-state interpretation.\n- `src/core/` owns provider-neutral contracts and shared lifecycle mechanisms, not concrete provider behavior.\n\nProvider-specific session fields belong behind typed helpers in the owning provider directory.\n\n## Naming Conventions\n\n- **Symbols**: no `I` prefix on interfaces. Treat acronyms as words (`SdkSessionReadResult`), except in types mirroring an external SDK (`SDKMessage`).\n- **Files**: name the file after its primary exported concept in `PascalCase.ts`; use `camelCase.ts` only for utility bags with no dominant export (when in doubt, `PascalCase`). Use `kebab-case.ts` only to mirror an external package name (`tests/__mocks__/claude-agent-sdk.ts`). Barrels stay `index.ts`, type buckets stay `types.ts`, tests mirror the source name plus `.test.ts` (qualifiers allowed: `fileLink.dom.test.ts`).\n- **Folders**: `kebab-case`.\n- **Imports**: no `.ts` extensions; prefer `@/` aliases over deep relative paths.\n\n## Development Rules\n\n- Write code, comments, identifiers, commit messages, and code blocks in English.\n- Do not use `console.*` in production code.\n- Settings writers must merge rather than replace provider-owned configuration.\n- Put non-committed notes, handoff files, traces, and throwaway scripts in `.context/`.\n\n## TDD Workflow\n\n- For new behavior or bug fixes, work one observable slice at a time: add or update the failing test in the mirrored `tests/` path, make it pass, then refactor.\n- Test through the closest stable owner or public interface; do not expose or test private methods only for convenience.\n- Mock environment and provider boundaries. Prefer real Claudian code, fixtures, or lightweight fakes for Claudian-owned collaborators.\n- For shared provider contracts, test provider-neutral behavior first, then cover each provider adapter's distinct behavior separately.\n- If a change cannot be tested directly, document why and cover the closest stable contract instead.\n\n## Provider Rules\n\n- Prefer provider-native behavior over local reimplementation. Adapt provider output at the boundary instead of shadowing provider features.\n- Keep live streaming and history replay responsibilities separate. Live output should come from the provider runtime protocol when available; provider transcript files are the replay source.\n- New provider behavior must be expressed through registries and capabilities: `ProviderRegistry`, `ProviderWorkspaceRegistry`, `ProviderChatUIConfig`, provider capabilities, and provider-owned settings reconciliation.\n- Model, permission, plan-mode, command, MCP, skill, and subagent behavior is provider-specific unless the core contract explicitly makes it shared.\n- Treat persisted provider configuration as untrusted runtime input. Provider settings readers and storage normalization must decode every field; invalid permission, tool, and sandbox modes must fail closed.\n- When provider behavior is uncertain, inspect real runtime output first. Put throwaway scripts, traces, and handoff notes in `.context/`.\n- Treat provider-native history and transcripts as read-only. Never mutate or delete provider session data when a Claudian conversation changes.\n- Only explicitly enabled models belong in the chat selector: no synthetic provider entries, no hidden session models, and no provider-default fallback when none are enabled.\n- Runtime-discovered commands are read-only in Claudian; providers own their editing and deletion.\n- Auxiliary query runners own their own process and session, independent from the chat runtime.\n\n## Review Checks\n\nReviews must enforce the dependency, ownership, provider-boundary, and state-lifetime constraints above.\n"},"files":{"AGENTS.md":"# AGENTS.md\n\n## Project\n\nClaudian is an Obsidian plugin that embeds provider-backed coding agents in a sidebar and inline-edit flow. Claude is the default provider. Codex, Grok, OpenCode, and Pi are optional providers that plug into the same conversation model through `Conversation.providerId` and opaque provider-owned `providerState`.\n\nDo not assume provider parity. Check each provider's `capabilities.ts`, `registration.ts`, and UI config before wiring shared behavior.\n\n## Scope Guides\n\n- Before editing a scoped area, read its nearest scoped guide:\n  - `src/app/AGENTS.md`\n  - `src/core/AGENTS.md`\n  - `src/features/chat/AGENTS.md`\n  - `src/providers/claude/AGENTS.md`\n  - `src/providers/codex/AGENTS.md`\n  - `src/providers/grok/AGENTS.md`\n  - `src/providers/opencode/AGENTS.md`\n  - `src/providers/pi/AGENTS.md`\n  - `src/style/AGENTS.md`\n\n## AGENTS.md Maintenance\n\n- AGENTS.md is execution context for agents, not general documentation. Keep only repository- or scope-specific information that a capable agent would not reliably know; every statement must change implementation, review, or verification behavior.\n- Keep repository-wide rules here; put local ownership, dependencies, invariants, failure modes, verification, and active decisions in the narrowest scoped guide that governs them.\n- Do not duplicate inherited guidance or silently contradict it. State a necessary local exception and its rationale explicitly.\n- Omit tours, ordinary implementation details, temporary status, and general engineering advice.\n- Record a decision only when it is active, surprising from the code, expensive to reverse, and reflects a real tradeoff. State the decision, rationale, and any concrete reconsideration condition; use Git history as the archive.\n- `CLAUDE.md` files should import the nearest `AGENTS.md`; do not duplicate shared guidance there.\n\n## Commands\n\n```bash\nnpm run dev\nnpm run build\nnpm run typecheck\nnpm run lint\nnpm run lint:fix\nnpm run test\nnpm run test:watch\nnpm run test:coverage\n```\n\nThe default full check is:\n\n```bash\nnpm run typecheck && npm run lint && npm run test && npm run build\n```\n\nTests mirror `src/` under `tests/unit/` and `tests/integration/`.\n\n## Architecture\n\nScoped guides define the source of truth and allowed mutators for state in their area.\n\n| Area | Responsibility |\n| --- | --- |\n| `src/main.ts` | Plugin lifecycle and concrete application composition |\n| `src/app/` | Application conversation, settings, provider-host, and storage services |\n| `src/core/` | Provider-neutral runtime, registry, storage, tool, and type contracts |\n| `src/providers/acp/` | Shared ACP transport, interaction, and session primitives without provider policy |\n| `src/providers/*/` | Provider adaptors, provider-owned runtime protocol, history, storage, settings, and UI |\n| `src/features/chat/` | Sidebar chat orchestration against provider-neutral contracts |\n| `src/features/inline-edit/` | Inline edit modal and provider-backed edit services |\n| `src/features/settings/` | Shared settings shell and provider tab assembly |\n| `src/shared/` | Reusable UI components |\n| `src/style/` | Modular CSS built into `styles.css` |\n\n### Dependency Direction\n\nIn the rules below, `A -> B` means `A` may import or call `B`:\n\n```text\ncomposition root (`src/main.ts`) -> app services + features + provider registrations + core\napp services -> core contracts\nfeatures -> FeatureHost + core contracts + shared UI\nproviders -> ProviderHost + core contracts + shared provider and UI primitives\n```\n\n- `core/` must not import feature code, app composition, or provider implementations.\n- Feature code must not import provider implementations. Resolve provider behavior through core registries and contracts.\n- Provider runtime and protocol code must not import chat views, feature controllers, or other feature orchestration.\n- Existing Claude compatibility re-exports that point into `src/app/` are migration seams, not an allowed general dependency direction. Do not add new provider-to-app imports; move shared contracts into `core/` when touching those seams materially.\n- `src/providers/acp/` may contain protocol primitives shared by ACP providers. Provider-specific launch policy, extensions, normalization, history, and state remain in the owning provider.\n- If a dependency does not fit these directions, introduce or extend an explicit contract at the owning boundary instead of reaching across layers.\n\n### Cross-Layer Ownership\n\n- `src/main.ts` owns plugin lifecycle and wiring; it does not become the home for feature or provider behavior.\n- `src/app/` owns application-scoped repositories, settings transactions, host adapters, and persistence coordination. See its scoped guide for exact state authority.\n- `src/features/*/` owns user-facing orchestration and presentation state, not provider-native processes or storage formats.\n- `src/providers/*/` owns native protocol, process, session, transcript, settings, and provider-state interpretation.\n- `src/core/` owns provider-neutral contracts and shared lifecycle mechanisms, not concrete provider behavior.\n\nProvider-specific session fields belong behind typed helpers in the owning provider directory.\n\n## Naming Conventions\n\n- **Symbols**: no `I` prefix on interfaces. Treat acronyms as words (`SdkSessionReadResult`), except in types mirroring an external SDK (`SDKMessage`).\n- **Files**: name the file after its primary exported concept in `PascalCase.ts`; use `camelCase.ts` only for utility bags with no dominant export (when in doubt, `PascalCase`). Use `kebab-case.ts` only to mirror an external package name (`tests/__mocks__/claude-agent-sdk.ts`). Barrels stay `index.ts`, type buckets stay `types.ts`, tests mirror the source name plus `.test.ts` (qualifiers allowed: `fileLink.dom.test.ts`).\n- **Folders**: `kebab-case`.\n- **Imports**: no `.ts` extensions; prefer `@/` aliases over deep relative paths.\n\n## Development Rules\n\n- Write code, comments, identifiers, commit messages, and code blocks in English.\n- Do not use `console.*` in production code.\n- Settings writers must merge rather than replace provider-owned configuration.\n- Put non-committed notes, handoff files, traces, and throwaway scripts in `.context/`.\n\n## TDD Workflow\n\n- For new behavior or bug fixes, work one observable slice at a time: add or update the failing test in the mirrored `tests/` path, make it pass, then refactor.\n- Test through the closest stable owner or public interface; do not expose or test private methods only for convenience.\n- Mock environment and provider boundaries. Prefer real Claudian code, fixtures, or lightweight fakes for Claudian-owned collaborators.\n- For shared provider contracts, test provider-neutral behavior first, then cover each provider adapter's distinct behavior separately.\n- If a change cannot be tested directly, document why and cover the closest stable contract instead.\n\n## Provider Rules\n\n- Prefer provider-native behavior over local reimplementation. Adapt provider output at the boundary instead of shadowing provider features.\n- Keep live streaming and history replay responsibilities separate. Live output should come from the provider runtime protocol when available; provider transcript files are the replay source.\n- New provider behavior must be expressed through registries and capabilities: `ProviderRegistry`, `ProviderWorkspaceRegistry`, `ProviderChatUIConfig`, provider capabilities, and provider-owned settings reconciliation.\n- Model, permission, plan-mode, command, MCP, skill, and subagent behavior is provider-specific unless the core contract explicitly makes it shared.\n- Treat persisted provider configuration as untrusted runtime input. Provider settings readers and storage normalization must decode every field; invalid permission, tool, and sandbox modes must fail closed.\n- When provider behavior is uncertain, inspect real runtime output first. Put throwaway scripts, traces, and handoff notes in `.context/`.\n- Treat provider-native history and transcripts as read-only. Never mutate or delete provider session data when a Claudian conversation changes.\n- Only explicitly enabled models belong in the chat selector: no synthetic provider entries, no hidden session models, and no provider-default fallback when none are enabled.\n- Runtime-discovered commands are read-only in Claudian; providers own their editing and deletion.\n- Auxiliary query runners own their own process and session, independent from the chat runtime.\n\n## Review Checks\n\nReviews must enforce the dependency, ownership, provider-boundary, and state-lifetime constraints above.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# AGENTS.md\n\n## Project\n\nClaudian is an Obsidian plugin that embeds provider-backed coding agents in a sidebar and inline-edit flow. Claude is the default provider. Codex, Grok, OpenCode, and Pi are optional providers that plug into the same conversation model through `Conversation.providerId` and opaque provider-owned `providerState`.\n\nDo not assume provider parity. Check each provider's `capabilities.ts`, `registration.ts`, and UI config before wiring shared behavior.\n\n## Scope Guides\n\n- Before editing a scoped area, read its nearest scoped guide:\n  - `src/app/AGENTS.md`\n  - `src/core/AGENTS.md`\n  - `src/features/chat/AGENTS.md`\n  - `src/providers/claude/AGENTS.md`\n  - `src/providers/codex/AGENTS.md`\n  - `src/providers/grok/AGENTS.md`\n  - `src/providers/opencode/AGENTS.md`\n  - `src/providers/pi/AGENTS.md`\n  - `src/style/AGENTS.md`\n\n## AGENTS.md Maintenance\n\n- AGENTS.md is execution context for agents, not general documentation. Keep only repository- or scope-specific information that a capable agent would not reliably know; every statement must change implementation, review, or verification behavior.\n- Keep repository-wide rules here; put local ownership, dependencies, invariants, failure modes, verification, and active decisions in the narrowest scoped guide that governs them.\n- Do not duplicate inherited guidance or silently contradict it. State a necessary local exception and its rationale explicitly.\n- Omit tours, ordinary implementation details, temporary status, and general engineering advice.\n- Record a decision only when it is active, surprising from the code, expensive to reverse, and reflects a real tradeoff. State the decision, rationale, and any concrete reconsideration condition; use Git history as the archive.\n- `CLAUDE.md` files should import the nearest `AGENTS.md`; do not duplicate shared guidance there.\n\n## Commands\n\n```bash\nnpm run dev\nnpm run build\nnpm run typecheck\nnpm run lint\nnpm run lint:fix\nnpm run test\nnpm run test:watch\nnpm run test:coverage\n```\n\nThe default full check is:\n\n```bash\nnpm run typecheck && npm run lint && npm run test && npm run build\n```\n\nTests mirror `src/` under `tests/unit/` and `tests/integration/`.\n\n## Architecture\n\nScoped guides define the source of truth and allowed mutators for state in their area.\n\n| Area | Responsibility |\n| --- | --- |\n| `src/main.ts` | Plugin lifecycle and concrete application composition |\n| `src/app/` | Application conversation, settings, provider-host, and storage services |\n| `src/core/` | Provider-neutral runtime, registry, storage, tool, and type contracts |\n| `src/providers/acp/` | Shared ACP transport, interaction, and session primitives without provider policy |\n| `src/providers/*/` | Provider adaptors, provider-owned runtime protocol, history, storage, settings, and UI |\n| `src/features/chat/` | Sidebar chat orchestration against provider-neutral contracts |\n| `src/features/inline-edit/` | Inline edit modal and provider-backed edit services |\n| `src/features/settings/` | Shared settings shell and provider tab assembly |\n| `src/shared/` | Reusable UI components |\n| `src/style/` | Modular CSS built into `styles.css` |\n\n### Dependency Direction\n\nIn the rules below, `A -> B` means `A` may import or call `B`:\n\n```text\ncomposition root (`src/main.ts`) -> app services + features + provider registrations + core\napp services -> core contracts\nfeatures -> FeatureHost + core contracts + shared UI\nproviders -> ProviderHost + core contracts + shared provider and UI primitives\n```\n\n- `core/` must not import feature code, app composition, or provider implementations.\n- Feature code must not import provider implementations. Resolve provider behavior through core registries and contracts.\n- Provider runtime and protocol code must not import chat views, feature controllers, or other feature orchestration.\n- Existing Claude compatibility re-exports that point into `src/app/` are migration seams, not an allowed general dependency direction. Do not add new provider-to-app imports; move shared contracts into `core/` when touching those seams materially.\n- `src/providers/acp/` may contain protocol primitives shared by ACP providers. Provider-specific launch policy, extensions, normalization, history, and state remain in the owning provider.\n- If a dependency does not fit these directions, introduce or extend an explicit contract at the owning boundary instead of reaching across layers.\n\n### Cross-Layer Ownership\n\n- `src/main.ts` owns plugin lifecycle and wiring; it does not become the home for feature or provider behavior.\n- `src/app/` owns application-scoped repositories, settings transactions, host adapters, and persistence coordination. See its scoped guide for exact state authority.\n- `src/features/*/` owns user-facing orchestration and presentation state, not provider-native processes or storage formats.\n- `src/providers/*/` owns native protocol, process, session, transcript, settings, and provider-state interpretation.\n- `src/core/` owns provider-neutral contracts and shared lifecycle mechanisms, not concrete provider behavior.\n\nProvider-specific session fields belong behind typed helpers in the owning provider directory.\n\n## Naming Conventions\n\n- **Symbols**: no `I` prefix on interfaces. Treat acronyms as words (`SdkSessionReadResult`), except in types mirroring an external SDK (`SDKMessage`).\n- **Files**: name the file after its primary exported concept in `PascalCase.ts`; use `camelCase.ts` only for utility bags with no dominant export (when in doubt, `PascalCase`). Use `kebab-case.ts` only to mirror an external package name (`tests/__mocks__/claude-agent-sdk.ts`). Barrels stay `index.ts`, type buckets stay `types.ts`, tests mirror the source name plus `.test.ts` (qualifiers allowed: `fileLink.dom.test.ts`).\n- **Folders**: `kebab-case`.\n- **Imports**: no `.ts` extensions; prefer `@/` aliases over deep relative paths.\n\n## Development Rules\n\n- Write code, comments, identifiers, commit messages, and code blocks in English.\n- Do not use `console.*` in production code.\n- Settings writers must merge rather than replace provider-owned configuration.\n- Put non-committed notes, handoff files, traces, and throwaway scripts in `.context/`.\n\n## TDD Workflow\n\n- For new behavior or bug fixes, work one observable slice at a time: add or update the failing test in the mirrored `tests/` path, make it pass, then refactor.\n- Test through the closest stable owner or public interface; do not expose or test private methods only for convenience.\n- Mock environment and provider boundaries. Prefer real Claudian code, fixtures, or lightweight fakes for Claudian-owned collaborators.\n- For shared provider contracts, test provider-neutral behavior first, then cover each provider adapter's distinct behavior separately.\n- If a change cannot be tested directly, document why and cover the closest stable contract instead.\n\n## Provider Rules\n\n- Prefer provider-native behavior over local reimplementation. Adapt provider output at the boundary instead of shadowing provider features.\n- Keep live streaming and history replay responsibilities separate. Live output should come from the provider runtime protocol when available; provider transcript files are the replay source.\n- New provider behavior must be expressed through registries and capabilities: `ProviderRegistry`, `ProviderWorkspaceRegistry`, `ProviderChatUIConfig`, provider capabilities, and provider-owned settings reconciliation.\n- Model, permission, plan-mode, command, MCP, skill, and subagent behavior is provider-specific unless the core contract explicitly makes it shared.\n- Treat persisted provider configuration as untrusted runtime input. Provider settings readers and storage normalization must decode every field; invalid permission, tool, and sandbox modes must fail closed.\n- When provider behavior is uncertain, inspect real runtime output first. Put throwaway scripts, traces, and handoff notes in `.context/`.\n- Treat provider-native history and transcripts as read-only. Never mutate or delete provider session data when a Claudian conversation changes.\n- Only explicitly enabled models belong in the chat selector: no synthetic provider entries, no hidden session models, and no provider-default fallback when none are enabled.\n- Runtime-discovered commands are read-only in Claudian; providers own their editing and deletion.\n- Auxiliary query runners own their own process and session, independent from the chat runtime.\n\n## Review Checks\n\nReviews must enforce the dependency, ownership, provider-boundary, and state-lifetime constraints above.\n","category":"root","tokens":2149}]}