{"owner":"usekaneo","repo":"kaneo","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md","AGENTS.md"],"skills":{"CLAUDE.md":"# Kaneo project instructions\n\nCanonical guidance: [AGENTS.md](./AGENTS.md)\n\n@AGENTS.md\n","AGENTS.md":"# Kaneo agent guide\n\nKaneo is a fast, deliberately simple, self-hosted project-management platform. The Hono API owns domain behavior and authorization, the React app consumes its typed client, PostgreSQL stores durable state, and events plus WebSockets keep clients current. Redis is optional and coordinates realtime delivery across multiple API instances.\n\nThis is an operating guide, not a README. These rules are good defaults; explicit developer and user instructions take precedence.\n\n## Principles\n\n- Simplicity is a product requirement. Build the smallest model that makes correct behavior obvious.\n- Features should solve a real problem without making routine work heavier.\n- Protect performance, especially on task-heavy boards and realtime views.\n- Keep self-hosting straightforward and single-instance deployments first-class. Do not make Redis or another managed service mandatory without an explicit product decision.\n- Support both bundled same-origin deployments and separately hosted API and web deployments.\n- Protect user data, workspace boundaries, and authorization checks.\n- Read the relevant implementation before changing it. Follow an established local pattern when it fits, but do not preserve accidental complexity merely because it exists.\n- Stay focused. Do not mix requested work with speculative features, broad refactors, or unrelated cleanup.\n\n## Architecture\n\n- `apps/api` — Hono API, Better Auth, controllers, database access, events, integrations, MCP HTTP routes, and WebSockets.\n- `apps/web` — React/Vite UI, TanStack Router and Query, fetchers, hooks, and realtime cache updates.\n- `apps/docs` — product and API documentation content; `apps/site` — public Next.js site and documentation host.\n- `packages/libs` — shared typed Hono client and URL helpers.\n- `packages/permissions` — canonical permission vocabulary and built-in roles.\n- `packages/mcp` — published stdio MCP package.\n- `charts/kaneo` — Helm deployment surface.\n- `tests/api` contains API unit tests; `tests/api-integration` contains PostgreSQL-backed integration tests.\n\n## Boundaries that must hold\n\n- The API is the authority for authentication and authorization. Hiding an action in the UI is not an authorization check.\n- Workspace-scoped operations must use the existing `@kaneo/permissions` vocabulary and API middleware.\n- Do not expose secrets, credentials, internal fields, or private workspace data through responses, logs, events, WebSockets, or MCP tools.\n- Public API behavior must retain accurate Valibot validation and OpenAPI metadata.\n- Mutations that affect realtime state must consider event publication, WebSocket delivery, and client cache invalidation.\n- Database changes must work for existing installations, not only empty development databases.\n- User-facing web copy must use static i18n keys. `i18n/en-US.json` is the source of truth.\n\n## Follow a change through\n\nBefore calling a behavior change complete, decide which surfaces apply:\n\n- API route, validator, controller, authorization, error behavior, and OpenAPI description.\n- Typed client, web fetcher, query or mutation hook, cache invalidation, and UI states.\n- Events, project- or user-scoped WebSockets, and optional Redis fan-out.\n- Permission definitions, API enforcement, and UI capability checks.\n- MCP, API keys, webhooks, and relevant external integrations.\n- Schema, relations, generated migration, indexes, cascades, and existing data.\n- Translations, accessibility, user documentation, Docker, and Helm.\n- Reverse states: create/delete, assign/unassign, enable/disable, connect/disconnect, and a visible current state.\n\nNot every change touches every surface. Make the decision deliberately rather than expanding scope automatically.\n\n## Project conventions\n\n- Keep API handlers thin and domain behavior in controllers or focused utilities.\n- Validate API inputs with Valibot unless an existing integration requires another library. Use `HTTPException` for expected HTTP failures.\n- Use `requireWorkspacePermission` rather than duplicating role checks.\n- Use `publishEvent()` when a mutation drives activity, notifications, integrations, or realtime updates.\n- Keep web requests in `apps/web/src/fetchers/` and server state in TanStack Query hooks.\n- Use the client from `@kaneo/libs`; do not create a parallel untyped request layer.\n- Define database schema in `apps/api/src/database/schema.ts` and relations in `apps/api/src/database/relations.ts`.\n- Generate migrations with `pnpm --filter @kaneo/api db:generate`, inspect the SQL, and include it with the schema change.\n- Prefer inferred TypeScript types and `type` over `interface` unless extension or declaration merging is required.\n- Comments should explain constraints or surprising decisions, not narrate code.\n\n## Safety and tooling\n\n- Use pnpm 10.32.1 and Node.js 20.19 or newer. Server environment variables come from the root `.env`; local Vite-only overrides belong in `apps/web/.env.local`. See `ENVIRONMENT_SETUP.md`.\n- Never use production databases, storage, or credentials for development or tests.\n- Preserve unrelated work in a dirty worktree. Do not delete data or generated files unless the task requires it and the target is verified.\n- Track processes you start and stop only those processes; never kill by broad name or path patterns.\n- The root and package `lint` scripts run Biome with `--write` and can modify unrelated files. Prefer targeted checks while iterating and inspect formatter changes.\n- Do not commit, push, or open a pull request unless explicitly requested.\n\n## Verification\n\nUse the smallest proof that covers the changed behavior, then broaden it when the blast radius requires it.\n\n- Utility or UI logic: focused unit/component tests and the affected package typecheck.\n- API behavior: focused API tests; use integration tests when routing, authentication, authorization, or PostgreSQL behavior matters.\n- Database changes: relevant integration tests and migration inspection.\n- Cross-package contracts: typecheck or build all affected consumers.\n- Realtime changes: verify the event-to-WebSocket-to-cache path and consider both in-memory and Redis delivery.\n- Deployment changes: validate the affected Docker, Helm, or startup path.\n- User-visible flows: use a real browser pass when requested or when it is the only meaningful proof.\n\nRun repository-wide checks when a change crosses packages broadly, before a requested commit or pull request, or when explicitly asked. Report what ran and what did not.\n\n## Glossary\n\n- **instance**: one deployed Kaneo installation.\n- **workspace**: the top-level collaboration and authorization boundary.\n- **project**: a task container inside a workspace.\n- **role**: a workspace-scoped set of permission statements.\n- **activity**: durable, user-visible history.\n- **event**: an internal notification used by activity, integrations, notifications, or realtime updates.\n\nUpdate this guide only for recurring, observed failure modes. Put narrow workflows in skills or dedicated documentation.\n"},"files":{"CLAUDE.md":"# Kaneo project instructions\n\nCanonical guidance: [AGENTS.md](./AGENTS.md)\n\n@AGENTS.md\n","AGENTS.md":"# Kaneo agent guide\n\nKaneo is a fast, deliberately simple, self-hosted project-management platform. The Hono API owns domain behavior and authorization, the React app consumes its typed client, PostgreSQL stores durable state, and events plus WebSockets keep clients current. Redis is optional and coordinates realtime delivery across multiple API instances.\n\nThis is an operating guide, not a README. These rules are good defaults; explicit developer and user instructions take precedence.\n\n## Principles\n\n- Simplicity is a product requirement. Build the smallest model that makes correct behavior obvious.\n- Features should solve a real problem without making routine work heavier.\n- Protect performance, especially on task-heavy boards and realtime views.\n- Keep self-hosting straightforward and single-instance deployments first-class. Do not make Redis or another managed service mandatory without an explicit product decision.\n- Support both bundled same-origin deployments and separately hosted API and web deployments.\n- Protect user data, workspace boundaries, and authorization checks.\n- Read the relevant implementation before changing it. Follow an established local pattern when it fits, but do not preserve accidental complexity merely because it exists.\n- Stay focused. Do not mix requested work with speculative features, broad refactors, or unrelated cleanup.\n\n## Architecture\n\n- `apps/api` — Hono API, Better Auth, controllers, database access, events, integrations, MCP HTTP routes, and WebSockets.\n- `apps/web` — React/Vite UI, TanStack Router and Query, fetchers, hooks, and realtime cache updates.\n- `apps/docs` — product and API documentation content; `apps/site` — public Next.js site and documentation host.\n- `packages/libs` — shared typed Hono client and URL helpers.\n- `packages/permissions` — canonical permission vocabulary and built-in roles.\n- `packages/mcp` — published stdio MCP package.\n- `charts/kaneo` — Helm deployment surface.\n- `tests/api` contains API unit tests; `tests/api-integration` contains PostgreSQL-backed integration tests.\n\n## Boundaries that must hold\n\n- The API is the authority for authentication and authorization. Hiding an action in the UI is not an authorization check.\n- Workspace-scoped operations must use the existing `@kaneo/permissions` vocabulary and API middleware.\n- Do not expose secrets, credentials, internal fields, or private workspace data through responses, logs, events, WebSockets, or MCP tools.\n- Public API behavior must retain accurate Valibot validation and OpenAPI metadata.\n- Mutations that affect realtime state must consider event publication, WebSocket delivery, and client cache invalidation.\n- Database changes must work for existing installations, not only empty development databases.\n- User-facing web copy must use static i18n keys. `i18n/en-US.json` is the source of truth.\n\n## Follow a change through\n\nBefore calling a behavior change complete, decide which surfaces apply:\n\n- API route, validator, controller, authorization, error behavior, and OpenAPI description.\n- Typed client, web fetcher, query or mutation hook, cache invalidation, and UI states.\n- Events, project- or user-scoped WebSockets, and optional Redis fan-out.\n- Permission definitions, API enforcement, and UI capability checks.\n- MCP, API keys, webhooks, and relevant external integrations.\n- Schema, relations, generated migration, indexes, cascades, and existing data.\n- Translations, accessibility, user documentation, Docker, and Helm.\n- Reverse states: create/delete, assign/unassign, enable/disable, connect/disconnect, and a visible current state.\n\nNot every change touches every surface. Make the decision deliberately rather than expanding scope automatically.\n\n## Project conventions\n\n- Keep API handlers thin and domain behavior in controllers or focused utilities.\n- Validate API inputs with Valibot unless an existing integration requires another library. Use `HTTPException` for expected HTTP failures.\n- Use `requireWorkspacePermission` rather than duplicating role checks.\n- Use `publishEvent()` when a mutation drives activity, notifications, integrations, or realtime updates.\n- Keep web requests in `apps/web/src/fetchers/` and server state in TanStack Query hooks.\n- Use the client from `@kaneo/libs`; do not create a parallel untyped request layer.\n- Define database schema in `apps/api/src/database/schema.ts` and relations in `apps/api/src/database/relations.ts`.\n- Generate migrations with `pnpm --filter @kaneo/api db:generate`, inspect the SQL, and include it with the schema change.\n- Prefer inferred TypeScript types and `type` over `interface` unless extension or declaration merging is required.\n- Comments should explain constraints or surprising decisions, not narrate code.\n\n## Safety and tooling\n\n- Use pnpm 10.32.1 and Node.js 20.19 or newer. Server environment variables come from the root `.env`; local Vite-only overrides belong in `apps/web/.env.local`. See `ENVIRONMENT_SETUP.md`.\n- Never use production databases, storage, or credentials for development or tests.\n- Preserve unrelated work in a dirty worktree. Do not delete data or generated files unless the task requires it and the target is verified.\n- Track processes you start and stop only those processes; never kill by broad name or path patterns.\n- The root and package `lint` scripts run Biome with `--write` and can modify unrelated files. Prefer targeted checks while iterating and inspect formatter changes.\n- Do not commit, push, or open a pull request unless explicitly requested.\n\n## Verification\n\nUse the smallest proof that covers the changed behavior, then broaden it when the blast radius requires it.\n\n- Utility or UI logic: focused unit/component tests and the affected package typecheck.\n- API behavior: focused API tests; use integration tests when routing, authentication, authorization, or PostgreSQL behavior matters.\n- Database changes: relevant integration tests and migration inspection.\n- Cross-package contracts: typecheck or build all affected consumers.\n- Realtime changes: verify the event-to-WebSocket-to-cache path and consider both in-memory and Redis delivery.\n- Deployment changes: validate the affected Docker, Helm, or startup path.\n- User-visible flows: use a real browser pass when requested or when it is the only meaningful proof.\n\nRun repository-wide checks when a change crosses packages broadly, before a requested commit or pull request, or when explicitly asked. Report what ran and what did not.\n\n## Glossary\n\n- **instance**: one deployed Kaneo installation.\n- **workspace**: the top-level collaboration and authorization boundary.\n- **project**: a task container inside a workspace.\n- **role**: a workspace-scoped set of permission statements.\n- **activity**: durable, user-visible history.\n- **event**: an internal notification used by activity, integrations, notifications, or realtime updates.\n\nUpdate this guide only for recurring, observed failure modes. Put narrow workflows in skills or dedicated documentation.\n"},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# Kaneo project instructions\n\nCanonical guidance: [AGENTS.md](./AGENTS.md)\n\n@AGENTS.md\n","category":"root","tokens":22},{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Kaneo agent guide\n\nKaneo is a fast, deliberately simple, self-hosted project-management platform. The Hono API owns domain behavior and authorization, the React app consumes its typed client, PostgreSQL stores durable state, and events plus WebSockets keep clients current. Redis is optional and coordinates realtime delivery across multiple API instances.\n\nThis is an operating guide, not a README. These rules are good defaults; explicit developer and user instructions take precedence.\n\n## Principles\n\n- Simplicity is a product requirement. Build the smallest model that makes correct behavior obvious.\n- Features should solve a real problem without making routine work heavier.\n- Protect performance, especially on task-heavy boards and realtime views.\n- Keep self-hosting straightforward and single-instance deployments first-class. Do not make Redis or another managed service mandatory without an explicit product decision.\n- Support both bundled same-origin deployments and separately hosted API and web deployments.\n- Protect user data, workspace boundaries, and authorization checks.\n- Read the relevant implementation before changing it. Follow an established local pattern when it fits, but do not preserve accidental complexity merely because it exists.\n- Stay focused. Do not mix requested work with speculative features, broad refactors, or unrelated cleanup.\n\n## Architecture\n\n- `apps/api` — Hono API, Better Auth, controllers, database access, events, integrations, MCP HTTP routes, and WebSockets.\n- `apps/web` — React/Vite UI, TanStack Router and Query, fetchers, hooks, and realtime cache updates.\n- `apps/docs` — product and API documentation content; `apps/site` — public Next.js site and documentation host.\n- `packages/libs` — shared typed Hono client and URL helpers.\n- `packages/permissions` — canonical permission vocabulary and built-in roles.\n- `packages/mcp` — published stdio MCP package.\n- `charts/kaneo` — Helm deployment surface.\n- `tests/api` contains API unit tests; `tests/api-integration` contains PostgreSQL-backed integration tests.\n\n## Boundaries that must hold\n\n- The API is the authority for authentication and authorization. Hiding an action in the UI is not an authorization check.\n- Workspace-scoped operations must use the existing `@kaneo/permissions` vocabulary and API middleware.\n- Do not expose secrets, credentials, internal fields, or private workspace data through responses, logs, events, WebSockets, or MCP tools.\n- Public API behavior must retain accurate Valibot validation and OpenAPI metadata.\n- Mutations that affect realtime state must consider event publication, WebSocket delivery, and client cache invalidation.\n- Database changes must work for existing installations, not only empty development databases.\n- User-facing web copy must use static i18n keys. `i18n/en-US.json` is the source of truth.\n\n## Follow a change through\n\nBefore calling a behavior change complete, decide which surfaces apply:\n\n- API route, validator, controller, authorization, error behavior, and OpenAPI description.\n- Typed client, web fetcher, query or mutation hook, cache invalidation, and UI states.\n- Events, project- or user-scoped WebSockets, and optional Redis fan-out.\n- Permission definitions, API enforcement, and UI capability checks.\n- MCP, API keys, webhooks, and relevant external integrations.\n- Schema, relations, generated migration, indexes, cascades, and existing data.\n- Translations, accessibility, user documentation, Docker, and Helm.\n- Reverse states: create/delete, assign/unassign, enable/disable, connect/disconnect, and a visible current state.\n\nNot every change touches every surface. Make the decision deliberately rather than expanding scope automatically.\n\n## Project conventions\n\n- Keep API handlers thin and domain behavior in controllers or focused utilities.\n- Validate API inputs with Valibot unless an existing integration requires another library. Use `HTTPException` for expected HTTP failures.\n- Use `requireWorkspacePermission` rather than duplicating role checks.\n- Use `publishEvent()` when a mutation drives activity, notifications, integrations, or realtime updates.\n- Keep web requests in `apps/web/src/fetchers/` and server state in TanStack Query hooks.\n- Use the client from `@kaneo/libs`; do not create a parallel untyped request layer.\n- Define database schema in `apps/api/src/database/schema.ts` and relations in `apps/api/src/database/relations.ts`.\n- Generate migrations with `pnpm --filter @kaneo/api db:generate`, inspect the SQL, and include it with the schema change.\n- Prefer inferred TypeScript types and `type` over `interface` unless extension or declaration merging is required.\n- Comments should explain constraints or surprising decisions, not narrate code.\n\n## Safety and tooling\n\n- Use pnpm 10.32.1 and Node.js 20.19 or newer. Server environment variables come from the root `.env`; local Vite-only overrides belong in `apps/web/.env.local`. See `ENVIRONMENT_SETUP.md`.\n- Never use production databases, storage, or credentials for development or tests.\n- Preserve unrelated work in a dirty worktree. Do not delete data or generated files unless the task requires it and the target is verified.\n- Track processes you start and stop only those processes; never kill by broad name or path patterns.\n- The root and package `lint` scripts run Biome with `--write` and can modify unrelated files. Prefer targeted checks while iterating and inspect formatter changes.\n- Do not commit, push, or open a pull request unless explicitly requested.\n\n## Verification\n\nUse the smallest proof that covers the changed behavior, then broaden it when the blast radius requires it.\n\n- Utility or UI logic: focused unit/component tests and the affected package typecheck.\n- API behavior: focused API tests; use integration tests when routing, authentication, authorization, or PostgreSQL behavior matters.\n- Database changes: relevant integration tests and migration inspection.\n- Cross-package contracts: typecheck or build all affected consumers.\n- Realtime changes: verify the event-to-WebSocket-to-cache path and consider both in-memory and Redis delivery.\n- Deployment changes: validate the affected Docker, Helm, or startup path.\n- User-visible flows: use a real browser pass when requested or when it is the only meaningful proof.\n\nRun repository-wide checks when a change crosses packages broadly, before a requested commit or pull request, or when explicitly asked. Report what ran and what did not.\n\n## Glossary\n\n- **instance**: one deployed Kaneo installation.\n- **workspace**: the top-level collaboration and authorization boundary.\n- **project**: a task container inside a workspace.\n- **role**: a workspace-scoped set of permission statements.\n- **activity**: durable, user-visible history.\n- **event**: an internal notification used by activity, integrations, notifications, or realtime updates.\n\nUpdate this guide only for recurring, observed failure modes. Put narrow workflows in skills or dedicated documentation.\n","category":"root","tokens":1757}]}