{"owner":"4gray","repo":"iptvnator","hasSkills":true,"totalSkillsCount":4,"totalTokensCount":3142,"categories":["root-instruction","mcp-config","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"iptvnator":{"command":"npx","args":["-y","@modelcontextprotocol/server-iptvnator"]}}},"found":["AGENTS.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json"],"skills":{"AGENTS.md":"# Repository guidance\n\nIPTVnator is an Angular/Electron IPTV player with a browser/PWA runtime.\nThese are the common instructions for all coding agents. Read the relevant\ncontracts below before changing a subsystem; do not load every document.\n\n## Bootstrap and commands\n\n- Use the Node version in `.nvmrc` and the repository's pnpm version.\n- In a fresh worktree, run `pnpm install --frozen-lockfile` before Nx discovery,\n  tests, lint or builds. Each worktree needs its own install.\n- Repeat the install after checkout changes, pulls, resets or rebases. Compare\n  `pnpm-lock.yaml` with `node_modules/.pnpm/lock.yaml`; a difference means stale\n  dependencies. Do not diagnose stale modules as application failures.\n- Verify discovery with `pnpm nx show projects`. Inspect the owning project's\n  targets before choosing checks. Prefer the smallest relevant Nx target.\n- Development: `pnpm run serve:frontend` or `pnpm run serve:backend`.\n- Tests: `pnpm nx test <project>`; lint: `pnpm nx lint <project>`.\n- Find checks and E2E commands in the [validation map](docs/architecture/validation-map.md).\n- Packaging, native dependencies and runtime patches have additional contracts\n  in the context map; read them before dependency or release changes.\n\n## Implementation invariants\n\n- Use scoped aliases from `tsconfig.base.json`, such as `@iptvnator/services`.\n  Do not introduce legacy bare aliases or bypass public project boundaries.\n- Nx projects keep `scope:*`, `domain:*` and `type:*` tags. Shared cross-project\n  files must belong to a project. SCSS imports need explicit hash dependencies.\n- Target under 300 production TypeScript lines; the hard limit is 400 (1200\n  for tests), excluding comments/blanks. Never add entries to the legacy baseline.\n- Preserve existing persisted data. Users may skip releases: migrations must\n  apply in dependency order, preserve data and be safe on repeated startup.\n  Test actual historical SQLite schemas, not only SQL mocks.\n- Choose runtime behavior through the relevant capability contract; a generic\n  `window.electron` check does not prove that a particular bridge is available.\n- Use shared redacting logging before emitting settings, portal or trace data.\n  Never log credentials or expanded SQL/bound values.\n- Keep UI consistent with the shared guidelines. Read the repository UI/theme\n  skills before changing user-visible Angular views or shared styles.\n\n## Validation and completion\n\n- Before finishing, assess affected projects and test impact. Bug fixes normally\n  include regression coverage that fails before the fix and passes afterwards.\n- Update stale tests, fixtures and E2E flows when behavior changes. Run targeted\n  unit checks and affected E2E for routing, persistence, playback and user flows.\n- Electron-only IPC, database, packaging, players and filesystem changes need\n  Electron E2E where available, otherwise CDP/manual validation with a reason.\n- Report checks and results, any skipped checks with reasons, documentation\n  changes, and whether a release note was added or why it was unnecessary.\n- Every user-visible change needs a note under `.changes/`; follow the\n  [release-note format](.changes/README.md) and the repository release-notes skill.\n  Docs, tests, CI and behavior-preserving refactors do not need a note. Apply\n  `no-release-note` on exempt PRs touching runtime code.\n- Validate notes with `pnpm run release:notes:validate`. Release publication has\n  separate ordered gates; follow the release-cut skill and release contract.\n- Before the first push of a pull-request branch, and before each later push to\n  an open pull request, pass the\n  [local review gate](docs/development/agent-workflow.md#local-review-before-a-pull-request):\n  Codex and Greptile CLI reviews of the committed branch, repeated until both\n  are clean. CI and the GitHub review bots confirm a branch; they are not its\n  first reviewer.\n\n## Performance threads\n\n- A journey thread targets one journey and one counter from the\n  [performance journeys contract](docs/architecture/performance-journeys.md);\n  name both in the PR. Performance work outside the journeys (compositing\n  budget, charset benchmark) follows its own section of that contract.\n  Reproduce with the matching benchmark before changing code, and put the\n  before/after table in the PR description.\n- Deterministic counters are the guardrail; wall-clock is evidence. Baselines in\n  `tools/performance/journey-baselines.json` move down with the Linux CI\n  runner's output as evidence; a deliberate increase needs the runner's value,\n  a `note` and the maintainer's `perf-baseline-increase` label\n  ([Ratchet](docs/architecture/performance-journeys.md#ratchet)). Never change\n  a probe or a journey to make a number pass.\n- Put user-visible performance changes behind a kill switch and remove it\n  within two releases. UX trade-offs and ratchet tolerances are maintainer\n  decisions: show the change and ask instead of deciding.\n- When a counter stops moving, say so and propose the next bottleneck. Working\n  rules and measurement hygiene:\n  [working a performance thread](docs/architecture/performance-journeys.md#working-a-performance-thread).\n\n## Keep guidance small and canonical\n\n- Update the affected subsystem's canonical document after meaningful changes.\n  Prefer an existing authoritative doc; keep user/developer entry points in\n  README and detailed contracts in architecture docs or a module README.\n- Add to this file only repository-wide rules and navigation. Implementation\n  details, incident history and multi-step procedures belong in linked docs.\n  Do not duplicate subsystem contracts here.\n- `AGENTS.md` is the single source of common rules for all agents, including\n  Claude Code. Limit: 200 lines / 16 KiB. Do not raise loading limits to fit\n  more prose. Claude Code setup is in the\n  [agent workflow](docs/development/agent-workflow.md#claude-code).\n- Read the [context map](docs/maintenance/agent-context-map.md) when ownership\n  is unclear. Read each affected domain for cross-domain tasks, not the whole map's documents.\n- Preserve exceptions and rationale when moving knowledge. Correct stale facts\n  against code; do not silently discard a contract. Maintenance details are in\n  the [agent workflow](docs/development/agent-workflow.md).\n- Never run whole-file `prettier --write` on AGENTS.md or `docs/**`.\n  Edit only intended lines; upstream Markdown is not uniformly Prettier-clean.\n- After changing guidance, run `pnpm run agents:validate`; after editing a\n  repository skill or a literal path it documents, run `pnpm run skills:validate`.\n  Keep release-cut and release-notes copies byte-identical for Codex and Claude.\n- Save finalized plans only in `.plans/YYYY-MM-DD-short-topic.md`; if a filename\n  exists, append `-2`, `-3`, etc. Respect active mode restrictions on file writes;\n  if writing is forbidden, save the approved plan when execution starts.\n\n## Read by task\n\n| Task | Required starting point |\n| --- | --- |\n| Project layout, imports, dependencies, lint configuration | [Nx boundaries](docs/architecture/nx-workspace-boundaries.md) |\n| Angular conventions, docs and skills maintenance | [Agent workflow](docs/development/agent-workflow.md) |\n| Electron debugging, CDP, trace flags | [Electron debugging](docs/development/electron-debugging.md) |\n| SQLite, worker IPC, persistence migrations | [DB worker](docs/architecture/sqlite-db-worker.md), [database migrations](libs/shared/database/README.md) |\n| M3U, XMLTV, startup, source health, OS playlist opening | [M3U contracts](docs/architecture/m3u-playlist-module.md), [adding sources across layers](docs/development/agent-workflow.md#adding-behavior-across-layers) |\n| Xtream / Stalker | [Xtream compatibility](docs/architecture/xtream-portal-compatibility.md), [Stalker contracts](docs/architecture/stalker-portal.md) (affected provider only) |\n| Player controls, diagnostics, radio, keep-awake | [Controls contract](docs/architecture/player-controls-contract.md) |\n| Embedded MPV, native runtime and packaging | [Embedded MPV](docs/architecture/embedded-mpv-native.md) |\n| UI, keyboard, detail navigation, remote control | [UI guidelines](docs/architecture/iptvnator-ui-guidelines.md), then matching topic in context map |\n| PWA, backend networking, connectivity guard | [PWA contract](docs/architecture/pwa-self-hosted.md), [host connectivity](docs/architecture/host-connectivity-guard.md) |\n| Downloads, TMDB, multi-source, workspace, backup, website | [Context map](docs/maintenance/agent-context-map.md) |\n| Startup time, bundle size, journeys, ratchet baselines | [Performance journeys](docs/architecture/performance-journeys.md), [working a thread](docs/architecture/performance-journeys.md#working-a-performance-thread) |\n| Release or packaging metadata | [Release pipeline](docs/architecture/release-pipeline.md), release-cut skill |\n\nRepository skills live in `.codex/skills/`. Their frontmatter owns trigger\nconditions; use the context map to locate a relevant skill. Read its linked\ncontract before editing. A missing optional global skill/tool is not a blocker:\nuse repository documentation and available CLI discovery.\n\n<!-- nx configuration start-->\n<!-- Leave the start & end comments to automatically receive updates. -->\n\n## General Guidelines for working with Nx\n\n- For workspace exploration, use the `nx-workspace` skill when available;\n  otherwise inspect project-local project.json files, `pnpm nx show projects` and `pnpm nx graph`.\n- Run project tasks through local `pnpm nx`, not a global Nx installation.\n- Use the Nx MCP server when available; otherwise use CLI discovery.\n- Check `node_modules/@nx/<plugin>/PLUGIN.md` for plugin guidance when present.\n- Never guess unfamiliar flags: consult `--help` or available `nx_docs`.\n\n## Scaffolding and generators\n\n- Use the `nx-generate` skill first when available. Otherwise discover the\n  generator with local Nx help and follow repository boundary rules.\n\n## When to use nx_docs\n\n- Use available `nx_docs` for migrations, unfamiliar configuration and flags.\n- Basic task syntax does not require a docs lookup; generator discovery belongs\n  to the generator skill or local CLI help.\n\n<!-- nx configuration end-->\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/4gray/iptvnator/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/4gray/iptvnator/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/4gray/iptvnator/HEAD/.claude-plugin/plugin.json)"},"files":{"AGENTS.md":"# Repository guidance\n\nIPTVnator is an Angular/Electron IPTV player with a browser/PWA runtime.\nThese are the common instructions for all coding agents. Read the relevant\ncontracts below before changing a subsystem; do not load every document.\n\n## Bootstrap and commands\n\n- Use the Node version in `.nvmrc` and the repository's pnpm version.\n- In a fresh worktree, run `pnpm install --frozen-lockfile` before Nx discovery,\n  tests, lint or builds. Each worktree needs its own install.\n- Repeat the install after checkout changes, pulls, resets or rebases. Compare\n  `pnpm-lock.yaml` with `node_modules/.pnpm/lock.yaml`; a difference means stale\n  dependencies. Do not diagnose stale modules as application failures.\n- Verify discovery with `pnpm nx show projects`. Inspect the owning project's\n  targets before choosing checks. Prefer the smallest relevant Nx target.\n- Development: `pnpm run serve:frontend` or `pnpm run serve:backend`.\n- Tests: `pnpm nx test <project>`; lint: `pnpm nx lint <project>`.\n- Find checks and E2E commands in the [validation map](docs/architecture/validation-map.md).\n- Packaging, native dependencies and runtime patches have additional contracts\n  in the context map; read them before dependency or release changes.\n\n## Implementation invariants\n\n- Use scoped aliases from `tsconfig.base.json`, such as `@iptvnator/services`.\n  Do not introduce legacy bare aliases or bypass public project boundaries.\n- Nx projects keep `scope:*`, `domain:*` and `type:*` tags. Shared cross-project\n  files must belong to a project. SCSS imports need explicit hash dependencies.\n- Target under 300 production TypeScript lines; the hard limit is 400 (1200\n  for tests), excluding comments/blanks. Never add entries to the legacy baseline.\n- Preserve existing persisted data. Users may skip releases: migrations must\n  apply in dependency order, preserve data and be safe on repeated startup.\n  Test actual historical SQLite schemas, not only SQL mocks.\n- Choose runtime behavior through the relevant capability contract; a generic\n  `window.electron` check does not prove that a particular bridge is available.\n- Use shared redacting logging before emitting settings, portal or trace data.\n  Never log credentials or expanded SQL/bound values.\n- Keep UI consistent with the shared guidelines. Read the repository UI/theme\n  skills before changing user-visible Angular views or shared styles.\n\n## Validation and completion\n\n- Before finishing, assess affected projects and test impact. Bug fixes normally\n  include regression coverage that fails before the fix and passes afterwards.\n- Update stale tests, fixtures and E2E flows when behavior changes. Run targeted\n  unit checks and affected E2E for routing, persistence, playback and user flows.\n- Electron-only IPC, database, packaging, players and filesystem changes need\n  Electron E2E where available, otherwise CDP/manual validation with a reason.\n- Report checks and results, any skipped checks with reasons, documentation\n  changes, and whether a release note was added or why it was unnecessary.\n- Every user-visible change needs a note under `.changes/`; follow the\n  [release-note format](.changes/README.md) and the repository release-notes skill.\n  Docs, tests, CI and behavior-preserving refactors do not need a note. Apply\n  `no-release-note` on exempt PRs touching runtime code.\n- Validate notes with `pnpm run release:notes:validate`. Release publication has\n  separate ordered gates; follow the release-cut skill and release contract.\n- Before the first push of a pull-request branch, and before each later push to\n  an open pull request, pass the\n  [local review gate](docs/development/agent-workflow.md#local-review-before-a-pull-request):\n  Codex and Greptile CLI reviews of the committed branch, repeated until both\n  are clean. CI and the GitHub review bots confirm a branch; they are not its\n  first reviewer.\n\n## Performance threads\n\n- A journey thread targets one journey and one counter from the\n  [performance journeys contract](docs/architecture/performance-journeys.md);\n  name both in the PR. Performance work outside the journeys (compositing\n  budget, charset benchmark) follows its own section of that contract.\n  Reproduce with the matching benchmark before changing code, and put the\n  before/after table in the PR description.\n- Deterministic counters are the guardrail; wall-clock is evidence. Baselines in\n  `tools/performance/journey-baselines.json` move down with the Linux CI\n  runner's output as evidence; a deliberate increase needs the runner's value,\n  a `note` and the maintainer's `perf-baseline-increase` label\n  ([Ratchet](docs/architecture/performance-journeys.md#ratchet)). Never change\n  a probe or a journey to make a number pass.\n- Put user-visible performance changes behind a kill switch and remove it\n  within two releases. UX trade-offs and ratchet tolerances are maintainer\n  decisions: show the change and ask instead of deciding.\n- When a counter stops moving, say so and propose the next bottleneck. Working\n  rules and measurement hygiene:\n  [working a performance thread](docs/architecture/performance-journeys.md#working-a-performance-thread).\n\n## Keep guidance small and canonical\n\n- Update the affected subsystem's canonical document after meaningful changes.\n  Prefer an existing authoritative doc; keep user/developer entry points in\n  README and detailed contracts in architecture docs or a module README.\n- Add to this file only repository-wide rules and navigation. Implementation\n  details, incident history and multi-step procedures belong in linked docs.\n  Do not duplicate subsystem contracts here.\n- `AGENTS.md` is the single source of common rules for all agents, including\n  Claude Code. Limit: 200 lines / 16 KiB. Do not raise loading limits to fit\n  more prose. Claude Code setup is in the\n  [agent workflow](docs/development/agent-workflow.md#claude-code).\n- Read the [context map](docs/maintenance/agent-context-map.md) when ownership\n  is unclear. Read each affected domain for cross-domain tasks, not the whole map's documents.\n- Preserve exceptions and rationale when moving knowledge. Correct stale facts\n  against code; do not silently discard a contract. Maintenance details are in\n  the [agent workflow](docs/development/agent-workflow.md).\n- Never run whole-file `prettier --write` on AGENTS.md or `docs/**`.\n  Edit only intended lines; upstream Markdown is not uniformly Prettier-clean.\n- After changing guidance, run `pnpm run agents:validate`; after editing a\n  repository skill or a literal path it documents, run `pnpm run skills:validate`.\n  Keep release-cut and release-notes copies byte-identical for Codex and Claude.\n- Save finalized plans only in `.plans/YYYY-MM-DD-short-topic.md`; if a filename\n  exists, append `-2`, `-3`, etc. Respect active mode restrictions on file writes;\n  if writing is forbidden, save the approved plan when execution starts.\n\n## Read by task\n\n| Task | Required starting point |\n| --- | --- |\n| Project layout, imports, dependencies, lint configuration | [Nx boundaries](docs/architecture/nx-workspace-boundaries.md) |\n| Angular conventions, docs and skills maintenance | [Agent workflow](docs/development/agent-workflow.md) |\n| Electron debugging, CDP, trace flags | [Electron debugging](docs/development/electron-debugging.md) |\n| SQLite, worker IPC, persistence migrations | [DB worker](docs/architecture/sqlite-db-worker.md), [database migrations](libs/shared/database/README.md) |\n| M3U, XMLTV, startup, source health, OS playlist opening | [M3U contracts](docs/architecture/m3u-playlist-module.md), [adding sources across layers](docs/development/agent-workflow.md#adding-behavior-across-layers) |\n| Xtream / Stalker | [Xtream compatibility](docs/architecture/xtream-portal-compatibility.md), [Stalker contracts](docs/architecture/stalker-portal.md) (affected provider only) |\n| Player controls, diagnostics, radio, keep-awake | [Controls contract](docs/architecture/player-controls-contract.md) |\n| Embedded MPV, native runtime and packaging | [Embedded MPV](docs/architecture/embedded-mpv-native.md) |\n| UI, keyboard, detail navigation, remote control | [UI guidelines](docs/architecture/iptvnator-ui-guidelines.md), then matching topic in context map |\n| PWA, backend networking, connectivity guard | [PWA contract](docs/architecture/pwa-self-hosted.md), [host connectivity](docs/architecture/host-connectivity-guard.md) |\n| Downloads, TMDB, multi-source, workspace, backup, website | [Context map](docs/maintenance/agent-context-map.md) |\n| Startup time, bundle size, journeys, ratchet baselines | [Performance journeys](docs/architecture/performance-journeys.md), [working a thread](docs/architecture/performance-journeys.md#working-a-performance-thread) |\n| Release or packaging metadata | [Release pipeline](docs/architecture/release-pipeline.md), release-cut skill |\n\nRepository skills live in `.codex/skills/`. Their frontmatter owns trigger\nconditions; use the context map to locate a relevant skill. Read its linked\ncontract before editing. A missing optional global skill/tool is not a blocker:\nuse repository documentation and available CLI discovery.\n\n<!-- nx configuration start-->\n<!-- Leave the start & end comments to automatically receive updates. -->\n\n## General Guidelines for working with Nx\n\n- For workspace exploration, use the `nx-workspace` skill when available;\n  otherwise inspect project-local project.json files, `pnpm nx show projects` and `pnpm nx graph`.\n- Run project tasks through local `pnpm nx`, not a global Nx installation.\n- Use the Nx MCP server when available; otherwise use CLI discovery.\n- Check `node_modules/@nx/<plugin>/PLUGIN.md` for plugin guidance when present.\n- Never guess unfamiliar flags: consult `--help` or available `nx_docs`.\n\n## Scaffolding and generators\n\n- Use the `nx-generate` skill first when available. Otherwise discover the\n  generator with local Nx help and follow repository boundary rules.\n\n## When to use nx_docs\n\n- Use available `nx_docs` for migrations, unfamiliar configuration and flags.\n- Basic task syntax does not require a docs lookup; generator discovery belongs\n  to the generator skill or local CLI help.\n\n<!-- nx configuration end-->\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/4gray/iptvnator/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/4gray/iptvnator/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/4gray/iptvnator/HEAD/.claude-plugin/plugin.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/4gray/iptvnator/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Repository guidance\n\nIPTVnator is an Angular/Electron IPTV player with a browser/PWA runtime.\nThese are the common instructions for all coding agents. Read the relevant\ncontracts below before changing a subsystem; do not load every document.\n\n## Bootstrap and commands\n\n- Use the Node version in `.nvmrc` and the repository's pnpm version.\n- In a fresh worktree, run `pnpm install --frozen-lockfile` before Nx discovery,\n  tests, lint or builds. Each worktree needs its own install.\n- Repeat the install after checkout changes, pulls, resets or rebases. Compare\n  `pnpm-lock.yaml` with `node_modules/.pnpm/lock.yaml`; a difference means stale\n  dependencies. Do not diagnose stale modules as application failures.\n- Verify discovery with `pnpm nx show projects`. Inspect the owning project's\n  targets before choosing checks. Prefer the smallest relevant Nx target.\n- Development: `pnpm run serve:frontend` or `pnpm run serve:backend`.\n- Tests: `pnpm nx test <project>`; lint: `pnpm nx lint <project>`.\n- Find checks and E2E commands in the [validation map](docs/architecture/validation-map.md).\n- Packaging, native dependencies and runtime patches have additional contracts\n  in the context map; read them before dependency or release changes.\n\n## Implementation invariants\n\n- Use scoped aliases from `tsconfig.base.json`, such as `@iptvnator/services`.\n  Do not introduce legacy bare aliases or bypass public project boundaries.\n- Nx projects keep `scope:*`, `domain:*` and `type:*` tags. Shared cross-project\n  files must belong to a project. SCSS imports need explicit hash dependencies.\n- Target under 300 production TypeScript lines; the hard limit is 400 (1200\n  for tests), excluding comments/blanks. Never add entries to the legacy baseline.\n- Preserve existing persisted data. Users may skip releases: migrations must\n  apply in dependency order, preserve data and be safe on repeated startup.\n  Test actual historical SQLite schemas, not only SQL mocks.\n- Choose runtime behavior through the relevant capability contract; a generic\n  `window.electron` check does not prove that a particular bridge is available.\n- Use shared redacting logging before emitting settings, portal or trace data.\n  Never log credentials or expanded SQL/bound values.\n- Keep UI consistent with the shared guidelines. Read the repository UI/theme\n  skills before changing user-visible Angular views or shared styles.\n\n## Validation and completion\n\n- Before finishing, assess affected projects and test impact. Bug fixes normally\n  include regression coverage that fails before the fix and passes afterwards.\n- Update stale tests, fixtures and E2E flows when behavior changes. Run targeted\n  unit checks and affected E2E for routing, persistence, playback and user flows.\n- Electron-only IPC, database, packaging, players and filesystem changes need\n  Electron E2E where available, otherwise CDP/manual validation with a reason.\n- Report checks and results, any skipped checks with reasons, documentation\n  changes, and whether a release note was added or why it was unnecessary.\n- Every user-visible change needs a note under `.changes/`; follow the\n  [release-note format](.changes/README.md) and the repository release-notes skill.\n  Docs, tests, CI and behavior-preserving refactors do not need a note. Apply\n  `no-release-note` on exempt PRs touching runtime code.\n- Validate notes with `pnpm run release:notes:validate`. Release publication has\n  separate ordered gates; follow the release-cut skill and release contract.\n- Before the first push of a pull-request branch, and before each later push to\n  an open pull request, pass the\n  [local review gate](docs/development/agent-workflow.md#local-review-before-a-pull-request):\n  Codex and Greptile CLI reviews of the committed branch, repeated until both\n  are clean. CI and the GitHub review bots confirm a branch; they are not its\n  first reviewer.\n\n## Performance threads\n\n- A journey thread targets one journey and one counter from the\n  [performance journeys contract](docs/architecture/performance-journeys.md);\n  name both in the PR. Performance work outside the journeys (compositing\n  budget, charset benchmark) follows its own section of that contract.\n  Reproduce with the matching benchmark before changing code, and put the\n  before/after table in the PR description.\n- Deterministic counters are the guardrail; wall-clock is evidence. Baselines in\n  `tools/performance/journey-baselines.json` move down with the Linux CI\n  runner's output as evidence; a deliberate increase needs the runner's value,\n  a `note` and the maintainer's `perf-baseline-increase` label\n  ([Ratchet](docs/architecture/performance-journeys.md#ratchet)). Never change\n  a probe or a journey to make a number pass.\n- Put user-visible performance changes behind a kill switch and remove it\n  within two releases. UX trade-offs and ratchet tolerances are maintainer\n  decisions: show the change and ask instead of deciding.\n- When a counter stops moving, say so and propose the next bottleneck. Working\n  rules and measurement hygiene:\n  [working a performance thread](docs/architecture/performance-journeys.md#working-a-performance-thread).\n\n## Keep guidance small and canonical\n\n- Update the affected subsystem's canonical document after meaningful changes.\n  Prefer an existing authoritative doc; keep user/developer entry points in\n  README and detailed contracts in architecture docs or a module README.\n- Add to this file only repository-wide rules and navigation. Implementation\n  details, incident history and multi-step procedures belong in linked docs.\n  Do not duplicate subsystem contracts here.\n- `AGENTS.md` is the single source of common rules for all agents, including\n  Claude Code. Limit: 200 lines / 16 KiB. Do not raise loading limits to fit\n  more prose. Claude Code setup is in the\n  [agent workflow](docs/development/agent-workflow.md#claude-code).\n- Read the [context map](docs/maintenance/agent-context-map.md) when ownership\n  is unclear. Read each affected domain for cross-domain tasks, not the whole map's documents.\n- Preserve exceptions and rationale when moving knowledge. Correct stale facts\n  against code; do not silently discard a contract. Maintenance details are in\n  the [agent workflow](docs/development/agent-workflow.md).\n- Never run whole-file `prettier --write` on AGENTS.md or `docs/**`.\n  Edit only intended lines; upstream Markdown is not uniformly Prettier-clean.\n- After changing guidance, run `pnpm run agents:validate`; after editing a\n  repository skill or a literal path it documents, run `pnpm run skills:validate`.\n  Keep release-cut and release-notes copies byte-identical for Codex and Claude.\n- Save finalized plans only in `.plans/YYYY-MM-DD-short-topic.md`; if a filename\n  exists, append `-2`, `-3`, etc. Respect active mode restrictions on file writes;\n  if writing is forbidden, save the approved plan when execution starts.\n\n## Read by task\n\n| Task | Required starting point |\n| --- | --- |\n| Project layout, imports, dependencies, lint configuration | [Nx boundaries](docs/architecture/nx-workspace-boundaries.md) |\n| Angular conventions, docs and skills maintenance | [Agent workflow](docs/development/agent-workflow.md) |\n| Electron debugging, CDP, trace flags | [Electron debugging](docs/development/electron-debugging.md) |\n| SQLite, worker IPC, persistence migrations | [DB worker](docs/architecture/sqlite-db-worker.md), [database migrations](libs/shared/database/README.md) |\n| M3U, XMLTV, startup, source health, OS playlist opening | [M3U contracts](docs/architecture/m3u-playlist-module.md), [adding sources across layers](docs/development/agent-workflow.md#adding-behavior-across-layers) |\n| Xtream / Stalker | [Xtream compatibility](docs/architecture/xtream-portal-compatibility.md), [Stalker contracts](docs/architecture/stalker-portal.md) (affected provider only) |\n| Player controls, diagnostics, radio, keep-awake | [Controls contract](docs/architecture/player-controls-contract.md) |\n| Embedded MPV, native runtime and packaging | [Embedded MPV](docs/architecture/embedded-mpv-native.md) |\n| UI, keyboard, detail navigation, remote control | [UI guidelines](docs/architecture/iptvnator-ui-guidelines.md), then matching topic in context map |\n| PWA, backend networking, connectivity guard | [PWA contract](docs/architecture/pwa-self-hosted.md), [host connectivity](docs/architecture/host-connectivity-guard.md) |\n| Downloads, TMDB, multi-source, workspace, backup, website | [Context map](docs/maintenance/agent-context-map.md) |\n| Startup time, bundle size, journeys, ratchet baselines | [Performance journeys](docs/architecture/performance-journeys.md), [working a thread](docs/architecture/performance-journeys.md#working-a-performance-thread) |\n| Release or packaging metadata | [Release pipeline](docs/architecture/release-pipeline.md), release-cut skill |\n\nRepository skills live in `.codex/skills/`. Their frontmatter owns trigger\nconditions; use the context map to locate a relevant skill. Read its linked\ncontract before editing. A missing optional global skill/tool is not a blocker:\nuse repository documentation and available CLI discovery.\n\n<!-- nx configuration start-->\n<!-- Leave the start & end comments to automatically receive updates. -->\n\n## General Guidelines for working with Nx\n\n- For workspace exploration, use the `nx-workspace` skill when available;\n  otherwise inspect project-local project.json files, `pnpm nx show projects` and `pnpm nx graph`.\n- Run project tasks through local `pnpm nx`, not a global Nx installation.\n- Use the Nx MCP server when available; otherwise use CLI discovery.\n- Check `node_modules/@nx/<plugin>/PLUGIN.md` for plugin guidance when present.\n- Never guess unfamiliar flags: consult `--help` or available `nx_docs`.\n\n## Scaffolding and generators\n\n- Use the `nx-generate` skill first when available. Otherwise discover the\n  generator with local Nx help and follow repository boundary rules.\n\n## When to use nx_docs\n\n- Use available `nx_docs` for migrations, unfamiliar configuration and flags.\n- Basic task syntax does not require a docs lookup; generator discovery belongs\n  to the generator skill or local CLI help.\n\n<!-- nx configuration end-->\n","isInternal":false,"tokens":2242,"sizeBytes":10217},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/4gray/iptvnator/HEAD/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/4gray/iptvnator/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":194},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/4gray/iptvnator/HEAD/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/4gray/iptvnator/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":180},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/4gray/iptvnator/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/4gray/iptvnator/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":173}],"systemPromptSnippet":"<yakaai_skills repo=\"4gray/iptvnator\">\n<!-- File: AGENTS.md (Tokens: ~2242 | Category: root-instruction) -->\n# Repository guidance\n\nIPTVnator is an Angular/Electron IPTV player with a browser/PWA runtime.\nThese are the common instructions for all coding agents. Read the relevant\ncontracts below before changing a subsystem; do not load every document.\n\n## Bootstrap and commands\n\n- Use the Node version in `.nvmrc` and the repository's pnpm version.\n- In a fresh worktree, run `pnpm install --frozen-lockfile` before Nx discovery,\n  tests, lint or builds. Each worktree needs its own install.\n- Repeat the install after checkout changes, pulls, resets or rebases. Compare\n  `pnpm-lock.yaml` with `node_modules/.pnpm/lock.yaml`; a difference means stale\n  dependencies. Do not diagnose stale modules as application failures.\n- Verify discovery with `pnpm nx show projects`. Inspect the owning project's\n  targets before choosing checks. Prefer the smallest relevant Nx target.\n- Development: `pnpm run serve:frontend` or `pnpm run serve:backend`.\n- Tests: `pnpm nx test <project>`; lint: `pnpm nx lint <project>`.\n- Find checks and E2E commands in the [validation map](docs/architecture/validation-map.md).\n- Packaging, native dependencies and runtime patches have additional contracts\n  in the context map; read them before dependency or release changes.\n\n## Implementation invariants\n\n- Use scoped aliases from `tsconfig.base.json`, such as `@iptvnator/services`.\n  Do not introduce legacy bare aliases or bypass public project boundaries.\n- Nx projects keep `scope:*`, `domain:*` and `type:*` tags. Shared cross-project\n  files must belong to a project. SCSS imports need explicit hash dependencies.\n- Target under 300 production TypeScript lines; the hard limit is 400 (1200\n  for tests), excluding comments/blanks. Never add entries to the legacy baseline.\n- Preserve existing persisted data. Users may skip releases: migrations must\n  apply in dependency order, preserve data and be safe on repeated startup.\n  Test actual historical SQLite schemas, not only SQL mocks.\n- Choose runtime behavior through the relevant capability contract; a generic\n  `window.electron` check does not prove that a particular bridge is available.\n- Use shared redacting logging before emitting settings, portal or trace data.\n  Never log credentials or expanded SQL/bound values.\n- Keep UI consistent with the shared guidelines. Read the repository UI/theme\n  skills before changing user-visible Angular views or shared styles.\n\n## Validation and completion\n\n- Before finishing, assess affected projects and test impact. Bug fixes normally\n  include regression coverage that fails before the fix and passes afterwards.\n- Update stale tests, fixtures and E2E flows when behavior changes. Run targeted\n  unit checks and affected E2E for routing, persistence, playback and user flows.\n- Electron-only IPC, database, packaging, players and filesystem changes need\n  Electron E2E where available, otherwise CDP/manual validation with a reason.\n- Report checks and results, any skipped checks with reasons, documentation\n  changes, and whether a release note was added or why it was unnecessary.\n- Every user-visible change needs a note under `.changes/`; follow the\n  [release-note format](.changes/README.md) and the repository release-notes skill.\n  Docs, tests, CI and behavior-preserving refactors do not need a note. Apply\n  `no-release-note` on exempt PRs touching runtime code.\n- Validate notes with `pnpm run release:notes:validate`. Release publication has\n  separate ordered gates; follow the release-cut skill and release contract.\n- Before the first push of a pull-request branch, and before each later push to\n  an open pull request, pass the\n  [local review gate](docs/development/agent-workflow.md#local-review-before-a-pull-request):\n  Codex and Greptile CLI reviews of the committed branch, repeated until both\n  are clean. CI and the GitHub review bots confirm a branch; they are not its\n  first reviewer.\n\n## Performance threads\n\n- A journey thread targets one journey and one counter from the\n  [performance journeys contract](docs/architecture/performance-journeys.md);\n  name both in the PR. Performance work outside the journeys (compositing\n  budget, charset benchmark) follows its own section of that contract.\n  Reproduce with the matching benchmark before changing code, and put the\n  before/after table in the PR description.\n- Deterministic counters are the guardrail; wall-clock is evidence. Baselines in\n  `tools/performance/journey-baselines.json` move down with the Linux CI\n  runner's output as evidence; a deliberate increase needs the runner's value,\n  a `note` and the maintainer's `perf-baseline-increase` label\n  ([Ratchet](docs/architecture/performance-journeys.md#ratchet)). Never change\n  a probe or a journey to make a number pass.\n- Put user-visible performance changes behind a kill switch and remove it\n  within two releases. UX trade-offs and ratchet tolerances are maintainer\n  decisions: show the change and ask instead of deciding.\n- When a counter stops moving, say so and propose the next bottleneck. Working\n  rules and measurement hygiene:\n  [working a performance thread](docs/architecture/performance-journeys.md#working-a-performance-thread).\n\n## Keep guidance small and canonical\n\n- Update the affected subsystem's canonical document after meaningful changes.\n  Prefer an existing authoritative doc; keep user/developer entry points in\n  README and detailed contracts in architecture docs or a module README.\n- Add to this file only repository-wide rules and navigation. Implementation\n  details, incident history and multi-step procedures belong in linked docs.\n  Do not duplicate subsystem contracts here.\n- `AGENTS.md` is the single source of common rules for all agents, including\n  Claude Code. Limit: 200 lines / 16 KiB. Do not raise loading limits to fit\n  more prose. Claude Code setup is in the\n  [agent workflow](docs/development/agent-workflow.md#claude-code).\n- Read the [context map](docs/maintenance/agent-context-map.md) when ownership\n  is unclear. Read each affected domain for cross-domain tasks, not the whole map's documents.\n- Preserve exceptions and rationale when moving knowledge. Correct stale facts\n  against code; do not silently discard a contract. Maintenance details are in\n  the [agent workflow](docs/development/agent-workflow.md).\n- Never run whole-file `prettier --write` on AGENTS.md or `docs/**`.\n  Edit only intended lines; upstream Markdown is not uniformly Prettier-clean.\n- After changing guidance, run `pnpm run agents:validate`; after editing a\n  repository skill or a literal path it documents, run `pnpm run skills:validate`.\n  Keep release-cut and release-notes copies byte-identical for Codex and Claude.\n- Save finalized plans only in `.plans/YYYY-MM-DD-short-topic.md`; if a filename\n  exists, append `-2`, `-3`, etc. Respect active mode restrictions on file writes;\n  if writing is forbidden, save the approved plan when execution starts.\n\n## Read by task\n\n| Task | Required starting point |\n| --- | --- |\n| Project layout, imports, dependencies, lint configuration | [Nx boundaries](docs/architecture/nx-workspace-boundaries.md) |\n| Angular conventions, docs and skills maintenance | [Agent workflow](docs/development/agent-workflow.md) |\n| Electron debugging, CDP, trace flags | [Electron debugging](docs/development/electron-debugging.md) |\n| SQLite, worker IPC, persistence migrations | [DB worker](docs/architecture/sqlite-db-worker.md), [database migrations](libs/shared/database/README.md) |\n| M3U, XMLTV, startup, source health, OS playlist opening | [M3U contracts](docs/architecture/m3u-playlist-module.md), [adding sources across layers](docs/development/agent-workflow.md#adding-behavior-across-layers) |\n| Xtream / Stalker | [Xtream compatibility](docs/architecture/xtream-portal-compatibility.md), [Stalker contracts](docs/architecture/stalker-portal.md) (affected provider only) |\n| Player controls, diagnostics, radio, keep-awake | [Controls contract](docs/architecture/player-controls-contract.md) |\n| Embedded MPV, native runtime and packaging | [Embedded MPV](docs/architecture/embedded-mpv-native.md) |\n| UI, keyboard, detail navigation, remote control | [UI guidelines](docs/architecture/iptvnator-ui-guidelines.md), then matching topic in context map |\n| PWA, backend networking, connectivity guard | [PWA contract](docs/architecture/pwa-self-hosted.md), [host connectivity](docs/architecture/host-connectivity-guard.md) |\n| Downloads, TMDB, multi-source, workspace, backup, website | [Context map](docs/maintenance/agent-context-map.md) |\n| Startup time, bundle size, journeys, ratchet baselines | [Performance journeys](docs/architecture/performance-journeys.md), [working a thread](docs/architecture/performance-journeys.md#working-a-performance-thread) |\n| Release or packaging metadata | [Release pipeline](docs/architecture/release-pipeline.md), release-cut skill |\n\nRepository skills live in `.codex/skills/`. Their frontmatter owns trigger\nconditions; use the context map to locate a relevant skill. Read its linked\ncontract before editing. A missing optional global skill/tool is not a blocker:\nuse repository documentation and available CLI discovery.\n\n<!-- nx configuration start-->\n<!-- Leave the start & end comments to automatically receive updates. -->\n\n## General Guidelines for working with Nx\n\n- For workspace exploration, use the `nx-workspace` skill when available;\n  otherwise inspect project-local project.json files, `pnpm nx show projects` and `pnpm nx graph`.\n- Run project tasks through local `pnpm nx`, not a global Nx installation.\n- Use the Nx MCP server when available; otherwise use CLI discovery.\n- Check `node_modules/@nx/<plugin>/PLUGIN.md` for plugin guidance when present.\n- Never guess unfamiliar flags: consult `--help` or available `nx_docs`.\n\n## Scaffolding and generators\n\n- Use the `nx-generate` skill first when available. Otherwise discover the\n  generator with local Nx help and follow repository boundary rules.\n\n## When to use nx_docs\n\n- Use available `nx_docs` for migrations, unfamiliar configuration and flags.\n- Basic task syntax does not require a docs lookup; generator discovery belongs\n  to the generator skill or local CLI help.\n\n<!-- nx configuration end-->\n\n<!-- File: .claude-plugin/marketplace.json (Tokens: ~300 | Category: marketplace) -->\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/4gray/iptvnator/HEAD/.claude-plugin/marketplace.json)\n\n<!-- File: .claude-plugin/plugin.json (Tokens: ~300 | Category: plugin-manifest) -->\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/4gray/iptvnator/HEAD/.claude-plugin/plugin.json)\n\n<!-- File: .cursor/mcp.json (Tokens: ~300 | Category: mcp-config) -->\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/4gray/iptvnator/HEAD/.cursor/mcp.json)\n</yakaai_skills>"}