{"owner":"every-app","repo":"open-seo","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md","CLAUDE.md"],"skills":{"AGENTS.md":"# Agent guidance\n\n## Engineering principles\n\n- Prefer simple, readable, flat code with minimal indirection.\n- Search for existing implementations and installed libraries before creating new helpers or abstractions.\n- Abstract when it prevents meaningful drift and makes the result simpler to maintain. Avoid speculative or one-use abstraction layers.\n- Keep product data normalized and relationships explicit. Do not encode relational data in JSON or text merely to avoid joins.\n- For new application-backed backend functionality, default to: TanStack server function → service → repository.\n- Keep schema changes, queries, and mutations compatible with both SQLite and Postgres.\n- Use idiomatic TypeScript. Use Zod to validate untrusted data and narrow runtime values at trust boundaries.\n- Prefer established project helpers and libraries over hand-rolled implementations.\n- Prefer idiomatic TanStack Query, Router, and Form patterns for server state, routing, and submitted forms.\n\n## Log papercuts\n\nWhen small, non-blocking repository friction occurs—a retried tool call, confusing setup step, flaky command, stale cache, misleading error, or non-obvious gotcha—use the `papercuts` skill and append it to `.agents/PAPERCUTS.md` in the moment. Continue the current task. Real bugs and tracked work are not papercuts, and sensitive data must never be logged.\n\nDo not mine an entire session for papercuts or start a broad cleanup unless the user explicitly asks.\n\n## Preserve review learnings\n\nAfter a merge-ready or other code review verifies a finding, use `maintain-greptile-rules` only when the finding exposes a recurring or high-risk repository invariant that existing `.greptile/` context and automated checks do not capture. Do not promote one-off bugs or preferences into permanent review rules.\n\nChanges to `.greptile/**`, `AGENTS.md`, `CLAUDE.md`, `.agents/skills/**`, and `.github/**` alter the review control plane and must receive explicit maintainer review. CODEOWNERS requests that review; where repository settings allow, enable GitHub's requirement for code-owner approval. Repository-specific rules live in `.greptile/`; maintainers should configure or retain a minimal org-enforced Greptile baseline for external-contribution, secret, authentication, billing, CI, and rule-tampering risks. Agents should report an unverified or missing baseline and must not mutate dashboard or organization rules without explicit user authorization.\n","CLAUDE.md":"# Agent guidance\n\n## Engineering principles\n\n- Prefer simple, readable, flat code with minimal indirection.\n- Search for existing implementations and installed libraries before creating new helpers or abstractions.\n- Abstract when it prevents meaningful drift and makes the result simpler to maintain. Avoid speculative or one-use abstraction layers.\n- Keep product data normalized and relationships explicit. Do not encode relational data in JSON or text merely to avoid joins.\n- For new application-backed backend functionality, default to: TanStack server function → service → repository.\n- Keep schema changes, queries, and mutations compatible with both SQLite and Postgres.\n- Use idiomatic TypeScript. Use Zod to validate untrusted data and narrow runtime values at trust boundaries.\n- Prefer established project helpers and libraries over hand-rolled implementations.\n- Prefer idiomatic TanStack Query, Router, and Form patterns for server state, routing, and submitted forms.\n\n## Testing\n\n- Don't add tests just for the sake of it. A test exists to enforce core behavior or a hard-to-spot edge case that could actually occur.\n- Keep tests as simple as possible, and always review them looking for simplifications.\n- Test behavior at the public entry point. Assert argument forwarding to a mocked collaborator only when that mapping is the contract (billing params, telemetry events).\n- Statically import the module under test. `vi.mock` is hoisted, so per-test `await import()` and `vi.resetModules()` are banned unless module-level state must reset — comment why.\n- Never re-declare a production class in a test. Import the real one; if the module is too heavy to import, move the class to a leaf module first (see `ga4Errors.ts`, `gscErrors.ts`).\n- `beforeEach` sets default mock return values only. Vitest's `clearMocks` already resets call state — no `mockReset`/`mockClear` ceremonies.\n- Fixtures contain only the fields the test asserts on or the types require. Shared shapes get a factory with overrides (see `ga4-test-fixtures.ts`, `tool-test-support.ts`); a fixture longer than its test's assertions is a smell.\n- One test per invariant. Don't re-test Zod or a library, and don't repeat an output-schema round-trip in every happy path.\n- Don't mock ORM builder chains. Test repositories through services or real SQL evaluation; chain mocks break on refactors that change no behavior.\n\n## Log papercuts\n\nWhen small, non-blocking repository friction occurs—a retried tool call, confusing setup step, flaky command, stale cache, misleading error, or non-obvious gotcha—use the `papercuts` skill and append it to `.agents/PAPERCUTS.md` in the moment. Continue the current task. Real bugs and tracked work are not papercuts, and sensitive data must never be logged.\n\nDo not mine an entire session for papercuts or start a broad cleanup unless the user explicitly asks.\n\n## Preserve review learnings\n\nAfter a merge-ready or other code review verifies a finding, use `maintain-greptile-rules` only when the finding exposes a recurring or high-risk repository invariant that existing `.greptile/` context and automated checks do not capture. Do not promote one-off bugs or preferences into permanent review rules.\n\nChanges to `.greptile/**`, `AGENTS.md`, `CLAUDE.md`, `.agents/skills/**`, and `.github/**` alter the review control plane and must receive explicit maintainer review. CODEOWNERS requests that review; where repository settings allow, enable GitHub's requirement for code-owner approval. Repository-specific rules live in `.greptile/`; maintainers should configure or retain a minimal org-enforced Greptile baseline for external-contribution, secret, authentication, billing, CI, and rule-tampering risks. Agents should report an unverified or missing baseline and must not mutate dashboard or organization rules without explicit user authorization.\n"},"files":{"AGENTS.md":"# Agent guidance\n\n## Engineering principles\n\n- Prefer simple, readable, flat code with minimal indirection.\n- Search for existing implementations and installed libraries before creating new helpers or abstractions.\n- Abstract when it prevents meaningful drift and makes the result simpler to maintain. Avoid speculative or one-use abstraction layers.\n- Keep product data normalized and relationships explicit. Do not encode relational data in JSON or text merely to avoid joins.\n- For new application-backed backend functionality, default to: TanStack server function → service → repository.\n- Keep schema changes, queries, and mutations compatible with both SQLite and Postgres.\n- Use idiomatic TypeScript. Use Zod to validate untrusted data and narrow runtime values at trust boundaries.\n- Prefer established project helpers and libraries over hand-rolled implementations.\n- Prefer idiomatic TanStack Query, Router, and Form patterns for server state, routing, and submitted forms.\n\n## Log papercuts\n\nWhen small, non-blocking repository friction occurs—a retried tool call, confusing setup step, flaky command, stale cache, misleading error, or non-obvious gotcha—use the `papercuts` skill and append it to `.agents/PAPERCUTS.md` in the moment. Continue the current task. Real bugs and tracked work are not papercuts, and sensitive data must never be logged.\n\nDo not mine an entire session for papercuts or start a broad cleanup unless the user explicitly asks.\n\n## Preserve review learnings\n\nAfter a merge-ready or other code review verifies a finding, use `maintain-greptile-rules` only when the finding exposes a recurring or high-risk repository invariant that existing `.greptile/` context and automated checks do not capture. Do not promote one-off bugs or preferences into permanent review rules.\n\nChanges to `.greptile/**`, `AGENTS.md`, `CLAUDE.md`, `.agents/skills/**`, and `.github/**` alter the review control plane and must receive explicit maintainer review. CODEOWNERS requests that review; where repository settings allow, enable GitHub's requirement for code-owner approval. Repository-specific rules live in `.greptile/`; maintainers should configure or retain a minimal org-enforced Greptile baseline for external-contribution, secret, authentication, billing, CI, and rule-tampering risks. Agents should report an unverified or missing baseline and must not mutate dashboard or organization rules without explicit user authorization.\n","CLAUDE.md":"# Agent guidance\n\n## Engineering principles\n\n- Prefer simple, readable, flat code with minimal indirection.\n- Search for existing implementations and installed libraries before creating new helpers or abstractions.\n- Abstract when it prevents meaningful drift and makes the result simpler to maintain. Avoid speculative or one-use abstraction layers.\n- Keep product data normalized and relationships explicit. Do not encode relational data in JSON or text merely to avoid joins.\n- For new application-backed backend functionality, default to: TanStack server function → service → repository.\n- Keep schema changes, queries, and mutations compatible with both SQLite and Postgres.\n- Use idiomatic TypeScript. Use Zod to validate untrusted data and narrow runtime values at trust boundaries.\n- Prefer established project helpers and libraries over hand-rolled implementations.\n- Prefer idiomatic TanStack Query, Router, and Form patterns for server state, routing, and submitted forms.\n\n## Testing\n\n- Don't add tests just for the sake of it. A test exists to enforce core behavior or a hard-to-spot edge case that could actually occur.\n- Keep tests as simple as possible, and always review them looking for simplifications.\n- Test behavior at the public entry point. Assert argument forwarding to a mocked collaborator only when that mapping is the contract (billing params, telemetry events).\n- Statically import the module under test. `vi.mock` is hoisted, so per-test `await import()` and `vi.resetModules()` are banned unless module-level state must reset — comment why.\n- Never re-declare a production class in a test. Import the real one; if the module is too heavy to import, move the class to a leaf module first (see `ga4Errors.ts`, `gscErrors.ts`).\n- `beforeEach` sets default mock return values only. Vitest's `clearMocks` already resets call state — no `mockReset`/`mockClear` ceremonies.\n- Fixtures contain only the fields the test asserts on or the types require. Shared shapes get a factory with overrides (see `ga4-test-fixtures.ts`, `tool-test-support.ts`); a fixture longer than its test's assertions is a smell.\n- One test per invariant. Don't re-test Zod or a library, and don't repeat an output-schema round-trip in every happy path.\n- Don't mock ORM builder chains. Test repositories through services or real SQL evaluation; chain mocks break on refactors that change no behavior.\n\n## Log papercuts\n\nWhen small, non-blocking repository friction occurs—a retried tool call, confusing setup step, flaky command, stale cache, misleading error, or non-obvious gotcha—use the `papercuts` skill and append it to `.agents/PAPERCUTS.md` in the moment. Continue the current task. Real bugs and tracked work are not papercuts, and sensitive data must never be logged.\n\nDo not mine an entire session for papercuts or start a broad cleanup unless the user explicitly asks.\n\n## Preserve review learnings\n\nAfter a merge-ready or other code review verifies a finding, use `maintain-greptile-rules` only when the finding exposes a recurring or high-risk repository invariant that existing `.greptile/` context and automated checks do not capture. Do not promote one-off bugs or preferences into permanent review rules.\n\nChanges to `.greptile/**`, `AGENTS.md`, `CLAUDE.md`, `.agents/skills/**`, and `.github/**` alter the review control plane and must receive explicit maintainer review. CODEOWNERS requests that review; where repository settings allow, enable GitHub's requirement for code-owner approval. Repository-specific rules live in `.greptile/`; maintainers should configure or retain a minimal org-enforced Greptile baseline for external-contribution, secret, authentication, billing, CI, and rule-tampering risks. Agents should report an unverified or missing baseline and must not mutate dashboard or organization rules without explicit user authorization.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Agent guidance\n\n## Engineering principles\n\n- Prefer simple, readable, flat code with minimal indirection.\n- Search for existing implementations and installed libraries before creating new helpers or abstractions.\n- Abstract when it prevents meaningful drift and makes the result simpler to maintain. Avoid speculative or one-use abstraction layers.\n- Keep product data normalized and relationships explicit. Do not encode relational data in JSON or text merely to avoid joins.\n- For new application-backed backend functionality, default to: TanStack server function → service → repository.\n- Keep schema changes, queries, and mutations compatible with both SQLite and Postgres.\n- Use idiomatic TypeScript. Use Zod to validate untrusted data and narrow runtime values at trust boundaries.\n- Prefer established project helpers and libraries over hand-rolled implementations.\n- Prefer idiomatic TanStack Query, Router, and Form patterns for server state, routing, and submitted forms.\n\n## Log papercuts\n\nWhen small, non-blocking repository friction occurs—a retried tool call, confusing setup step, flaky command, stale cache, misleading error, or non-obvious gotcha—use the `papercuts` skill and append it to `.agents/PAPERCUTS.md` in the moment. Continue the current task. Real bugs and tracked work are not papercuts, and sensitive data must never be logged.\n\nDo not mine an entire session for papercuts or start a broad cleanup unless the user explicitly asks.\n\n## Preserve review learnings\n\nAfter a merge-ready or other code review verifies a finding, use `maintain-greptile-rules` only when the finding exposes a recurring or high-risk repository invariant that existing `.greptile/` context and automated checks do not capture. Do not promote one-off bugs or preferences into permanent review rules.\n\nChanges to `.greptile/**`, `AGENTS.md`, `CLAUDE.md`, `.agents/skills/**`, and `.github/**` alter the review control plane and must receive explicit maintainer review. CODEOWNERS requests that review; where repository settings allow, enable GitHub's requirement for code-owner approval. Repository-specific rules live in `.greptile/`; maintainers should configure or retain a minimal org-enforced Greptile baseline for external-contribution, secret, authentication, billing, CI, and rule-tampering risks. Agents should report an unverified or missing baseline and must not mutate dashboard or organization rules without explicit user authorization.\n","category":"root","tokens":614},{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# Agent guidance\n\n## Engineering principles\n\n- Prefer simple, readable, flat code with minimal indirection.\n- Search for existing implementations and installed libraries before creating new helpers or abstractions.\n- Abstract when it prevents meaningful drift and makes the result simpler to maintain. Avoid speculative or one-use abstraction layers.\n- Keep product data normalized and relationships explicit. Do not encode relational data in JSON or text merely to avoid joins.\n- For new application-backed backend functionality, default to: TanStack server function → service → repository.\n- Keep schema changes, queries, and mutations compatible with both SQLite and Postgres.\n- Use idiomatic TypeScript. Use Zod to validate untrusted data and narrow runtime values at trust boundaries.\n- Prefer established project helpers and libraries over hand-rolled implementations.\n- Prefer idiomatic TanStack Query, Router, and Form patterns for server state, routing, and submitted forms.\n\n## Testing\n\n- Don't add tests just for the sake of it. A test exists to enforce core behavior or a hard-to-spot edge case that could actually occur.\n- Keep tests as simple as possible, and always review them looking for simplifications.\n- Test behavior at the public entry point. Assert argument forwarding to a mocked collaborator only when that mapping is the contract (billing params, telemetry events).\n- Statically import the module under test. `vi.mock` is hoisted, so per-test `await import()` and `vi.resetModules()` are banned unless module-level state must reset — comment why.\n- Never re-declare a production class in a test. Import the real one; if the module is too heavy to import, move the class to a leaf module first (see `ga4Errors.ts`, `gscErrors.ts`).\n- `beforeEach` sets default mock return values only. Vitest's `clearMocks` already resets call state — no `mockReset`/`mockClear` ceremonies.\n- Fixtures contain only the fields the test asserts on or the types require. Shared shapes get a factory with overrides (see `ga4-test-fixtures.ts`, `tool-test-support.ts`); a fixture longer than its test's assertions is a smell.\n- One test per invariant. Don't re-test Zod or a library, and don't repeat an output-schema round-trip in every happy path.\n- Don't mock ORM builder chains. Test repositories through services or real SQL evaluation; chain mocks break on refactors that change no behavior.\n\n## Log papercuts\n\nWhen small, non-blocking repository friction occurs—a retried tool call, confusing setup step, flaky command, stale cache, misleading error, or non-obvious gotcha—use the `papercuts` skill and append it to `.agents/PAPERCUTS.md` in the moment. Continue the current task. Real bugs and tracked work are not papercuts, and sensitive data must never be logged.\n\nDo not mine an entire session for papercuts or start a broad cleanup unless the user explicitly asks.\n\n## Preserve review learnings\n\nAfter a merge-ready or other code review verifies a finding, use `maintain-greptile-rules` only when the finding exposes a recurring or high-risk repository invariant that existing `.greptile/` context and automated checks do not capture. Do not promote one-off bugs or preferences into permanent review rules.\n\nChanges to `.greptile/**`, `AGENTS.md`, `CLAUDE.md`, `.agents/skills/**`, and `.github/**` alter the review control plane and must receive explicit maintainer review. CODEOWNERS requests that review; where repository settings allow, enable GitHub's requirement for code-owner approval. Repository-specific rules live in `.greptile/`; maintainers should configure or retain a minimal org-enforced Greptile baseline for external-contribution, secret, authentication, billing, CI, and rule-tampering risks. Agents should report an unverified or missing baseline and must not mutate dashboard or organization rules without explicit user authorization.\n","category":"root","tokens":968}]}