kartman-dev 1.0.0-dev.0 → 1.0.0-dev.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "kartman-dev",
-  "version": "1.0.0-dev.0",
+  "version": "1.0.0-dev.1",
   "description": "CLI for running Claude agents in Vercel sandboxes",
   "type": "module",
   "main": "./dist/index.js",

package/dist/claude-config/worktrees/polymorphic-cooking-goose/.claude/.claude-plugin/plugin.json

@@ -1,11 +0,0 @@
-{
-  "name": "claude-linear-agent",
-  "version": "0.1.0",
-  "description": "Skills and MCP integrations for the Linear AI agent — Linear, GitHub, Notion, and Context7",
-  "author": {
-    "name": "Matt Aliev"
-  },
-  "repository": "https://github.com/mattaliev/claude-linear-agent",
-  "license": "MIT",
-  "keywords": ["linear", "agent", "mcp", "notion", "github", "context7"]
-}

package/dist/claude-config/worktrees/polymorphic-cooking-goose/.claude/.mcp.json

@@ -1,23 +0,0 @@
-{
-  "mcpServers": {
-    "linear": {
-      "type": "http",
-      "url": "https://mcp.linear.app/mcp",
-      "headers": {
-        "Authorization": "Bearer ${LINEAR_ACCESS_TOKEN}"
-      }
-    },
-    "notion": {
-      "type": "http",
-      "url": "https://mcp.notion.com/mcp",
-      "headers": {
-        "Authorization": "Bearer ${NOTION_API_KEY}",
-        "Notion-Version": "2025-09-03"
-      }
-    },
-    "context7": {
-      "command": "npx",
-      "args": ["-y", "@upstash/context7-mcp", "--api-key", "${CONTEXT7_API_KEY}"]
-    }
-  }
-}

package/dist/claude-config/worktrees/polymorphic-cooking-goose/.claude/settings.json

@@ -1,13 +0,0 @@
-{
-  "enabledPlugins": {
-    "agent-sdk-dev@claude-plugins-official": true,
-    "plugin-dev@claude-plugins-official": true,
-    "code-simplifier@claude-plugins-official": true,
-    "code-review@claude-plugins-official": true,
-    "pr-review-toolkit@claude-plugins-official": true
-  },
-  "env": {
-    "ENABLE_TOOL_SEARCH": "true",
-    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
-  }
-}

package/dist/claude-config/worktrees/polymorphic-cooking-goose/.claude/skills/doc-drift-check/SKILL.md

@@ -1,140 +0,0 @@
----
-name: Doc Drift Check
-description: This skill should be used when the user asks to "check docs for drift", "compare code changes against documentation", "review docs after PR", "find outdated documentation", "check if docs match the code", "verify documentation is up to date", or after completing a pull request review to verify documentation accuracy. Analyzes code changes against project docs, CLAUDE.md, database schema, Notion module pages, and Notion processes to catch mismatches.
----
-
-# Doc Drift Check
-
-Analyze code changes from a PR or issue against all project documentation — both in the repository and in Notion — to catch mismatches that would lead to stale docs. Write a severity-categorized comment to the Linear issue only when meaningful drift is found.
-
-## When to Use
-
-Invoke manually after reviewing a pull request or completing an issue review. Skip for trivial changes (typo fixes, formatting, dependency bumps) where doc drift is impossible.
-
-## Workflow
-
-### 1. Gather Context
-
-Collect three inputs before analysis:
-
-**Code changes** — Get the diff for the issue's PR:
-- Use GitHub MCP to read the PR diff
-- Note which files changed and the nature of changes (new files, modified APIs, removed features, config changes, model changes, service changes)
-
-**Linear issue** — Read the issue description and metadata:
-- Issue title, description, and acceptance criteria
-- Team identifier (determines which Notion workspace to check):
-  - `KPL-` → Platform
-  - `KPE-` → Personal
-  - `KBU-` → Business
-- Links to Notion pages or external docs in the description
-
-**Repository documentation** — Read relevant local docs:
-- `docs/` directory — scan for files related to changed code areas
-- `CLAUDE.md` — project overview, architecture, env vars, structure
-- Database schema files — check if schema changes are reflected
-
-### 2. Identify Relevant Notion Documentation
-
-Based on the team identifier from the Linear issue, fetch the corresponding Product Development page in Notion. These pages contain module documentation, processes, and feature documents for each team.
-
-**Team → Notion Product Development page mapping:**
-
-| Team Prefix | Team | Notion Page ID |
-|---|---|---|
-| `KPL-` | Platform | `24c80383e1518012a3c2c410588782d5` |
-| `KPE-` | Personal | `23a80383e15180ae91bae32b407ebaf9` |
-| `KBU-` | Business | `24c80383e15180e19e78cfca4b49fe66` |
-
-**Scan the Product Development page** for the appropriate team:
-1. Fetch the page and scan its child pages
-2. Identify module pages that relate to the changed code area
-3. Read those module pages — they describe models, services, and APIs for each module
-
-**Check the Processes database** (`252cc951ac514d86ad3b6d9fc689409c`):
-1. The Processes database has a "Модули" relation linking processes to modules
-2. If code changes affect a module, find linked processes
-3. Check if process descriptions still match the implementation
-
-### 3. Analyze for Mismatches
-
-Compare code changes against each relevant documentation source. Look for:
-
-- **Model drift** — Code adds/removes/renames model fields, but module documentation in Notion still describes the old schema
-- **Service drift** — New services added or service logic changed, but module page doesn't list them
-- **API drift** — Endpoints added/changed/removed, but docs still reference old API
-- **Process drift** — Implementation changes how a process works, but the process page in Notion doesn't reflect it
-- **Missing documentation** — New module, feature, or config with no corresponding docs
-- **Stale references** — Docs reference removed code, old file paths, or deprecated models
-- **Issue description mismatch** — What was implemented differs from what the issue describes
-- **Structural drift** — File/directory structure changed but project structure docs not updated
-- **Environment drift** — New env vars, config values, or dependencies not documented
-
-For detailed severity classification examples, consult `references/severity-guide.md`.
-
-### 4. Decision Gate
-
-After analysis, decide whether to comment:
-
-- **No mismatches found** → Do nothing. Do not write a "no issues found" comment.
-- **Only trivial mismatches** (e.g., a slightly outdated example that doesn't mislead) → Skip.
-- **Meaningful mismatches** → Proceed to write comment.
-
-The bar for commenting: would someone reading the docs be misled or confused by the current state? If yes, comment. If not, skip.
-
-### 5. Write Linear Comment
-
-Post a comment on the Linear issue using this format:
-
-```
-📋 Doc Drift Report
-
-[1-2 sentence summary of what was found]
-
-🔴 Critical
-- [Notion: Module "Payments" → Models section] — Code adds TransferFee model but module page doesn't list it
-- [File: `CLAUDE.md` env vars table] — New SYNC_API_KEY env var required but not listed
-
-🟡 Moderate
-- [Notion: Process "Customer Onboarding"] — Step 3 now calls ProviderService instead of direct API, process diagram outdated
-- [File: `docs/architecture.md`] — New endpoint POST /api/v2/transfers not documented
-
-🟢 Light
-- [Notion: Module "Crypto" → Services section] — CryptoSigningService renamed to AccessKeyService in code
-
----
-Suggested actions:
-- Update Notion module page "Payments" with new TransferFee model
-- Add SYNC_API_KEY to CLAUDE.md environment variables table
-- Update process diagram in "Customer Onboarding" process page
-```
-
-**Formatting rules:**
-- Use severity emojis: 🔴 Critical, 🟡 Moderate, 🟢 Light
-- Prefix with source: `[Notion: ...]` or `[File: ...]`
-- Include specific page/section references
-- Include a "Suggested actions" section with concrete fixes
-- Omit empty severity categories
-
-## Severity Classification Quick Reference
-
-| Severity | Description |
-|---|---|
-| 🔴 Critical | Model/schema changes undocumented, API changes, env var changes, breaking behavior, architecture shifts — someone would build against wrong assumptions |
-| 🟡 Moderate | New services undocumented, process flow changes, new features without docs, workflow changes — someone would miss important capabilities |
-| 🟢 Light | Renamed entities, outdated examples, minor wording, service method renames — someone might be briefly confused |
-
-For detailed examples and edge cases, see `references/severity-guide.md`.
-
-## Tools Used
-
-- **GitHub MCP** — read PR diffs and changed files
-- **Linear MCP** — read issue description and team, post comments
-- **Notion MCP** — fetch Product Development pages, module pages, process pages
-- **Read, Grep, Glob** — scan local documentation files in the repository
-
-## Additional Resources
-
-### Reference Files
-
-- **`references/severity-guide.md`** — Detailed severity classification with examples, edge cases, and per-source guidance

package/dist/claude-config/worktrees/polymorphic-cooking-goose/.claude/skills/doc-drift-check/references/severity-guide.md

@@ -1,174 +0,0 @@
-# Severity Classification Guide
-
-Detailed guide for categorizing doc drift findings by severity level. Use this when analyzing mismatches between code changes and documentation.
-
-## 🔴 Critical — Would Cause Wrong Assumptions
-
-These mismatches would cause someone to build against incorrect assumptions or make wrong decisions.
-
-### Model/Schema Changes
-
-- Code adds a new model but the Notion module page doesn't list it
-- Code removes or renames a model field, but the module documentation still references the old field
-- Relationship between models changed (e.g., ForeignKey → ManyToMany) but not reflected in docs
-- New required field added to a model but not documented in the module's models section
-
-**Example:**
-> Code adds `AccessKey` model to `andgate_crypto` module, but the Crypto module page in Notion under Platform's Product Development doesn't mention it.
-
-### API/Endpoint Changes
-
-- New endpoint added without documentation
-- Endpoint removed but still listed in docs
-- Request/response format changed but docs show old format
-- Authentication requirements changed
-
-### Environment & Configuration
-
-- New environment variable required but not in CLAUDE.md or deployment docs
-- Configuration option removed but still documented
-- Default value changed for existing config
-
-### Architecture Changes
-
-- New module/app created without corresponding Notion documentation
-- Service dependencies changed (module A now depends on module B, but docs don't show this)
-- Database migration adds/removes tables not reflected in schema docs
-
----
-
-## 🟡 Moderate — Would Miss Important Capabilities
-
-These mismatches would cause someone to miss important features or follow outdated procedures.
-
-### Service Changes
-
-- New service class added to a module but module page doesn't list it in the services section
-- Service method signature changed (different params) but process docs reference old signature
-- Service now calls a different external provider but process diagrams show old flow
-
-**Example:**
-> Code adds `AccessKeyService` to handle crypto signing, but the Crypto module page doesn't list it under Services.
-
-### Process Flow Changes
-
-- Steps in a business process reordered or modified
-- New step added to a process (e.g., new validation step in onboarding)
-- Conditional logic changed (e.g., different handling for B2B vs B2C)
-- Process now has prerequisites that aren't documented
-
-**Example:**
-> Customer onboarding now requires provider-specific KYC before account creation, but the process page still shows a single KYC step.
-
-### Feature Documentation Gaps
-
-- New feature implemented but no feature document exists
-- Feature behavior changed significantly but feature docs describe old behavior
-- Feature flag added without documentation in relevant places
-
-### Workflow Changes
-
-- Webhook handling changed but webhook documentation outdated
-- Background task behavior modified but not reflected in process docs
-- Error handling strategy changed for a module
-
----
-
-## 🟢 Light — Brief Confusion Only
-
-These mismatches would cause someone brief confusion but wouldn't lead to incorrect work.
-
-### Naming/Renaming
-
-- Service or utility class renamed but docs use old name
-- File moved to different directory but docs reference old path
-- Variable or constant renamed
-
-**Example:**
-> `CryptoSigningService` renamed to `AccessKeyService` in code but Notion module page still says `CryptoSigningService`.
-
-### Outdated Examples
-
-- Code example in docs uses old import path
-- Example shows deprecated API usage but functionally equivalent
-- Test examples reference old fixtures
-
-### Minor Wording
-
-- Documentation says "will be implemented" for already-implemented features
-- Status markers (TODO, WIP) left in docs for completed work
-- Comments in code reference old Notion page names
-
----
-
-## Per-Source Analysis Guide
-
-### Notion Module Pages
-
-Module pages describe models and services for each module. When checking:
-
-1. **Models section** — Compare listed models against actual Django models in the code
-2. **Services section** — Compare listed services against actual service classes
-3. **API section** — Compare listed endpoints against actual URL configs
-4. **Shared models** — Verify cross-module dependencies are still accurate
-5. **Dependency graph** — Check if module interdependencies changed
-
-### Notion Processes Database
-
-Process pages describe business workflows. When checking:
-
-1. **Process steps** — Do the documented steps match the actual code flow?
-2. **Prerequisites** — Are process prerequisites still accurate?
-3. **Provider interactions** — Do provider-specific flows match current implementation?
-4. **Status transitions** — Do documented state machines match code?
-5. **Related modules** — Is the "Модули" relation still correct?
-
-### Repository docs/ Directory
-
-Local documentation files. When checking:
-
-1. **Architecture docs** — Do they reflect current module structure?
-2. **API docs** — Do endpoint descriptions match implementations?
-3. **Setup/deployment docs** — Are instructions still accurate?
-
-### CLAUDE.md
-
-Project-level documentation. When checking:
-
-1. **Environment variables table** — All required vars listed?
-2. **Project structure** — Does the tree match actual directory layout?
-3. **Technology stack** — Any new dependencies or tools?
-4. **Key documentation links** — Do referenced docs still exist?
-
-### Database Schema
-
-Schema documentation. When checking:
-
-1. **Table definitions** — Do they match current migrations?
-2. **Relationships** — Are FK/M2M relations documented correctly?
-3. **Indexes** — Any new indexes not mentioned in schema docs?
-4. **New tables** — Any new migrations creating tables not in schema docs?
-
----
-
-## Edge Cases
-
-### When NOT to Flag
-
-- Code comments that are slightly outdated (not worth a Linear comment)
-- Test file documentation being slightly behind (tests are self-documenting)
-- Third-party library version bumps with no behavior change
-- Formatting-only changes to documentation files
-- Internal refactoring that doesn't change public interfaces or behavior
-
-### When to Escalate to Critical
-
-Even if a change seems small, escalate if:
-- It affects an external-facing API that developers build against
-- It changes model fields that other services query
-- It modifies environment variables needed for deployment
-- It alters the behavior described in a process that operations follows
-
-### Multiple Small Issues
-
-If there are many Light issues (5+) concentrated in one documentation area, consider grouping them and elevating to a single Moderate finding with a suggestion to do a documentation review for that area.

package/dist/claude-config/worktrees/valiant-sparking-hare/.claude/.claude-plugin/plugin.json

@@ -1,11 +0,0 @@
-{
-  "name": "kartman",
-  "version": "0.1.0",
-  "description": "Skills and MCP integrations for the Linear AI agent — Linear, GitHub, Notion, and Context7",
-  "author": {
-    "name": "Matt Aliev"
-  },
-  "repository": "https://github.com/mattaliev/kartman",
-  "license": "MIT",
-  "keywords": ["linear", "agent", "mcp", "notion", "github", "context7"]
-}

package/dist/claude-config/worktrees/valiant-sparking-hare/.claude/.mcp.json

@@ -1,23 +0,0 @@
-{
-  "mcpServers": {
-    "linear": {
-      "type": "http",
-      "url": "https://mcp.linear.app/mcp",
-      "headers": {
-        "Authorization": "Bearer ${LINEAR_ACCESS_TOKEN}"
-      }
-    },
-    "notion": {
-      "type": "http",
-      "url": "https://mcp.notion.com/mcp",
-      "headers": {
-        "Authorization": "Bearer ${NOTION_API_KEY}",
-        "Notion-Version": "2025-09-03"
-      }
-    },
-    "context7": {
-      "command": "npx",
-      "args": ["-y", "@upstash/context7-mcp", "--api-key", "${CONTEXT7_API_KEY}"]
-    }
-  }
-}

package/dist/claude-config/worktrees/valiant-sparking-hare/.claude/commands/linear-issue.md

@@ -1,59 +0,0 @@
----
-name: linear-issue
-description: Load a Linear issue into context. Provide an issue ID or derive it from the current branch name.
-argument-hint: "[ISSUE-ID] [--branch]"
----
-
-# Load Linear Issue
-
-Load a Linear issue into context to work on it.
-
-**User arguments:** $ARGUMENTS
-
-## Step 1: Parse Arguments
-
-Parse the arguments string above:
-- If it contains an issue identifier (e.g. `KPE-143`, `KR-1032` — format: 2-4 uppercase letters, dash, number), use that as the issue ID
-- If it contains `--branch`, the user wants a branch created for this issue
-- If no issue identifier is provided, derive it from the current git branch name:
-  1. Run `git branch --show-current` to get the current branch
-  2. Extract the issue identifier from the branch name. Common patterns:
-     - `{prefix}-{TEAM}-{number}-{slug}` → extract `{TEAM}-{number}` (e.g. `MAT-KPL-56-add-auth` → `KPL-56`)
-     - `feature/{TEAM}-{number}_{slug}` → extract `{TEAM}-{number}`
-     - `{TEAM}-{number}-{slug}` → extract `{TEAM}-{number}`
-  3. If no identifier can be extracted, ask the user for the issue ID
-
-## Step 2: Fetch the Issue from Linear
-
-Use the Linear MCP to fetch the issue details:
-1. Search for the issue by its identifier
-2. Load the full issue including: title, description, state, priority, assignee, labels, comments, and parent issue/project info
-3. If the issue has a project, note the project name and ID for context
-
-## Step 3: Display Issue Context
-
-Present the issue information clearly:
-- **Identifier and Title**
-- **Status** and **Priority**
-- **Description** (full text)
-- **Labels** and **Assignee**
-- **Project** (if any)
-- **Key comments** (especially any progress checkpoints from previous sessions)
-
-## Step 4: Branch Creation (only if --branch was passed)
-
-If `--branch` was in the arguments:
-
-1. Read the repository's `CLAUDE.md` and `docs/git-conventions.md` (if it exists) to understand branching conventions
-2. Also check recent branches with `git branch -a` to understand the naming pattern used in this repo
-3. Determine the correct branch name following the repo's conventions. If no convention is found, default to: `feature/{issue-identifier}_{short-slug}` where `{short-slug}` is a kebab-case summary of the issue title (keep it concise, 2-4 words)
-4. Check if a branch for this issue already exists: `git branch -a | grep -i {issue-identifier}`
-   - If a branch already exists, check it out instead of creating a new one
-   - Tell the user you found an existing branch and checked it out
-5. If no existing branch, create and checkout the new branch from the current branch: `git checkout -b {branch-name}`
-
-## Important Notes
-
-- This command is used across multiple repositories. Always check the current repository's `CLAUDE.md` and recent branches/PRs to follow its specific conventions.
-- If the issue has checkpoint comments from previous sessions, highlight the most recent one — it contains the continuation point.
-- Keep the output concise but complete. The user needs enough context to start working on the issue.

package/dist/claude-config/worktrees/valiant-sparking-hare/.claude/commands/linear-project.md

@@ -1,70 +0,0 @@
----
-name: linear-project
-description: Load a Linear project into context. Provide a project name or derive it from the current branch's issue.
-argument-hint: "[PROJECT-NAME] [--branch]"
----
-
-# Load Linear Project
-
-Load a Linear project into context to work on it.
-
-**User arguments:** $ARGUMENTS
-
-## Step 1: Parse Arguments
-
-Parse the arguments string above:
-- If it contains a project name (any text that isn't `--branch`), use that to search for the project in Linear
-- If it contains `--branch`, the user wants a feature branch created for this project
-- If no project name is provided, derive it from the current branch:
-  1. Run `git branch --show-current` to get the current branch
-  2. Extract the issue identifier from the branch name. Common patterns:
-     - `{prefix}-{TEAM}-{number}-{slug}` → extract `{TEAM}-{number}` (e.g. `MAT-KPL-56-add-auth` → `KPL-56`)
-     - `feature/{TEAM}-{number}_{slug}` → extract `{TEAM}-{number}`
-     - `{TEAM}-{number}-{slug}` → extract `{TEAM}-{number}`
-  3. Use the Linear MCP to fetch that issue and find which project it belongs to
-  4. If the issue doesn't belong to a project, or no identifier can be extracted, ask the user for the project name
-
-## Step 2: Fetch the Project from Linear
-
-Use the Linear MCP to load the full project details:
-1. Project name, description, status, lead, and members
-2. All issues in the project — with their identifiers, titles, statuses, priorities, and assignees
-3. Any project updates or milestones
-
-## Step 3: Display Project Context
-
-Present the project information clearly:
-
-- **Project Name** and **Status**
-- **Description** (full text)
-- **Lead** and **Members**
-- **Progress** — count of issues by status (e.g. 5 Done, 3 In Progress, 8 Todo)
-
-### Issues Breakdown
-
-List all project issues grouped by status, showing:
-- Identifier, title, priority, assignee
-- Highlight any blocked issues
-
-### Recent Updates
-
-Show any recent project updates or milestone comments.
-
-## Step 4: Branch Creation (only if --branch was passed)
-
-If `--branch` was in the arguments:
-
-1. Read the repository's `CLAUDE.md` and `docs/git-conventions.md` (if it exists) to understand branching conventions for feature/project branches
-2. Also check recent branches with `git branch -a` to understand the naming pattern used in this repo
-3. Determine the correct branch name following the repo's conventions. If no convention is found, default to: `feature/{short-project-slug}` where `{short-project-slug}` is a kebab-case version of the project name (e.g. "Модуль Payments" → `feature/payments`)
-4. Check if a branch for this project already exists: look for branches that match the project theme in `git branch -a`
-   - If a matching branch already exists, check it out instead of creating a new one
-   - Tell the user you found an existing branch and checked it out
-5. If no existing branch, create and checkout the new branch from the current branch: `git checkout -b {branch-name}`
-
-## Important Notes
-
-- This command is used across multiple repositories. Always check the current repository's `CLAUDE.md` and recent branches/PRs to follow its specific conventions.
-- For projects with many issues, organize the display so it's scannable — group by status, sort by priority within groups.
-- If the project has a Notion planning document linked, mention it so the user can reference it.
-- Keep the output concise but complete. The user needs the full project picture to make decisions.

package/dist/claude-config/worktrees/valiant-sparking-hare/.claude/settings.json

@@ -1,13 +0,0 @@
-{
-  "enabledPlugins": {
-    "agent-sdk-dev@claude-plugins-official": true,
-    "plugin-dev@claude-plugins-official": true,
-    "code-simplifier@claude-plugins-official": true,
-    "code-review@claude-plugins-official": true,
-    "pr-review-toolkit@claude-plugins-official": true
-  },
-  "env": {
-    "ENABLE_TOOL_SEARCH": "true",
-    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
-  }
-}

package/dist/claude-config/worktrees/valiant-sparking-hare/.claude/skills/doc-drift-check/SKILL.md

@@ -1,140 +0,0 @@
----
-name: Doc Drift Check
-description: This skill should be used when the user asks to "check docs for drift", "compare code changes against documentation", "review docs after PR", "find outdated documentation", "check if docs match the code", "verify documentation is up to date", or after completing a pull request review to verify documentation accuracy. Analyzes code changes against project docs, CLAUDE.md, database schema, Notion module pages, and Notion processes to catch mismatches.
----
-
-# Doc Drift Check
-
-Analyze code changes from a PR or issue against all project documentation — both in the repository and in Notion — to catch mismatches that would lead to stale docs. Write a severity-categorized comment to the Linear issue only when meaningful drift is found.
-
-## When to Use
-
-Invoke manually after reviewing a pull request or completing an issue review. Skip for trivial changes (typo fixes, formatting, dependency bumps) where doc drift is impossible.
-
-## Workflow
-
-### 1. Gather Context
-
-Collect three inputs before analysis:
-
-**Code changes** — Get the diff for the issue's PR:
-- Use GitHub MCP to read the PR diff
-- Note which files changed and the nature of changes (new files, modified APIs, removed features, config changes, model changes, service changes)
-
-**Linear issue** — Read the issue description and metadata:
-- Issue title, description, and acceptance criteria
-- Team identifier (determines which Notion workspace to check):
-  - `KPL-` → Platform
-  - `KPE-` → Personal
-  - `KBU-` → Business
-- Links to Notion pages or external docs in the description
-
-**Repository documentation** — Read relevant local docs:
-- `docs/` directory — scan for files related to changed code areas
-- `CLAUDE.md` — project overview, architecture, env vars, structure
-- Database schema files — check if schema changes are reflected
-
-### 2. Identify Relevant Notion Documentation
-
-Based on the team identifier from the Linear issue, fetch the corresponding Product Development page in Notion. These pages contain module documentation, processes, and feature documents for each team.
-
-**Team → Notion Product Development page mapping:**
-
-| Team Prefix | Team | Notion Page ID |
-|---|---|---|
-| `KPL-` | Platform | `24c80383e1518012a3c2c410588782d5` |
-| `KPE-` | Personal | `23a80383e15180ae91bae32b407ebaf9` |
-| `KBU-` | Business | `24c80383e15180e19e78cfca4b49fe66` |
-
-**Scan the Product Development page** for the appropriate team:
-1. Fetch the page and scan its child pages
-2. Identify module pages that relate to the changed code area
-3. Read those module pages — they describe models, services, and APIs for each module
-
-**Check the Processes database** (`252cc951ac514d86ad3b6d9fc689409c`):
-1. The Processes database has a "Модули" relation linking processes to modules
-2. If code changes affect a module, find linked processes
-3. Check if process descriptions still match the implementation
-
-### 3. Analyze for Mismatches
-
-Compare code changes against each relevant documentation source. Look for:
-
-- **Model drift** — Code adds/removes/renames model fields, but module documentation in Notion still describes the old schema
-- **Service drift** — New services added or service logic changed, but module page doesn't list them
-- **API drift** — Endpoints added/changed/removed, but docs still reference old API
-- **Process drift** — Implementation changes how a process works, but the process page in Notion doesn't reflect it
-- **Missing documentation** — New module, feature, or config with no corresponding docs
-- **Stale references** — Docs reference removed code, old file paths, or deprecated models
-- **Issue description mismatch** — What was implemented differs from what the issue describes
-- **Structural drift** — File/directory structure changed but project structure docs not updated
-- **Environment drift** — New env vars, config values, or dependencies not documented
-
-For detailed severity classification examples, consult `references/severity-guide.md`.
-
-### 4. Decision Gate
-
-After analysis, decide whether to comment:
-
-- **No mismatches found** → Do nothing. Do not write a "no issues found" comment.
-- **Only trivial mismatches** (e.g., a slightly outdated example that doesn't mislead) → Skip.
-- **Meaningful mismatches** → Proceed to write comment.
-
-The bar for commenting: would someone reading the docs be misled or confused by the current state? If yes, comment. If not, skip.
-
-### 5. Write Linear Comment
-
-Post a comment on the Linear issue using this format:
-
-```
-📋 Doc Drift Report
-
-[1-2 sentence summary of what was found]
-
-🔴 Critical
-- [Notion: Module "Payments" → Models section] — Code adds TransferFee model but module page doesn't list it
-- [File: `CLAUDE.md` env vars table] — New SYNC_API_KEY env var required but not listed
-
-🟡 Moderate
-- [Notion: Process "Customer Onboarding"] — Step 3 now calls ProviderService instead of direct API, process diagram outdated
-- [File: `docs/architecture.md`] — New endpoint POST /api/v2/transfers not documented
-
-🟢 Light
-- [Notion: Module "Crypto" → Services section] — CryptoSigningService renamed to AccessKeyService in code
-
----
-Suggested actions:
-- Update Notion module page "Payments" with new TransferFee model
-- Add SYNC_API_KEY to CLAUDE.md environment variables table
-- Update process diagram in "Customer Onboarding" process page
-```
-
-**Formatting rules:**
-- Use severity emojis: 🔴 Critical, 🟡 Moderate, 🟢 Light
-- Prefix with source: `[Notion: ...]` or `[File: ...]`
-- Include specific page/section references
-- Include a "Suggested actions" section with concrete fixes
-- Omit empty severity categories
-
-## Severity Classification Quick Reference
-
-| Severity | Description |
-|---|---|
-| 🔴 Critical | Model/schema changes undocumented, API changes, env var changes, breaking behavior, architecture shifts — someone would build against wrong assumptions |
-| 🟡 Moderate | New services undocumented, process flow changes, new features without docs, workflow changes — someone would miss important capabilities |
-| 🟢 Light | Renamed entities, outdated examples, minor wording, service method renames — someone might be briefly confused |
-
-For detailed examples and edge cases, see `references/severity-guide.md`.
-
-## Tools Used
-
-- **GitHub MCP** — read PR diffs and changed files
-- **Linear MCP** — read issue description and team, post comments
-- **Notion MCP** — fetch Product Development pages, module pages, process pages
-- **Read, Grep, Glob** — scan local documentation files in the repository
-
-## Additional Resources
-
-### Reference Files
-
-- **`references/severity-guide.md`** — Detailed severity classification with examples, edge cases, and per-source guidance

package/dist/claude-config/worktrees/valiant-sparking-hare/.claude/skills/doc-drift-check/references/severity-guide.md

@@ -1,174 +0,0 @@
-# Severity Classification Guide
-
-Detailed guide for categorizing doc drift findings by severity level. Use this when analyzing mismatches between code changes and documentation.
-
-## 🔴 Critical — Would Cause Wrong Assumptions
-
-These mismatches would cause someone to build against incorrect assumptions or make wrong decisions.
-
-### Model/Schema Changes
-
-- Code adds a new model but the Notion module page doesn't list it
-- Code removes or renames a model field, but the module documentation still references the old field
-- Relationship between models changed (e.g., ForeignKey → ManyToMany) but not reflected in docs
-- New required field added to a model but not documented in the module's models section
-
-**Example:**
-> Code adds `AccessKey` model to `andgate_crypto` module, but the Crypto module page in Notion under Platform's Product Development doesn't mention it.
-
-### API/Endpoint Changes
-
-- New endpoint added without documentation
-- Endpoint removed but still listed in docs
-- Request/response format changed but docs show old format
-- Authentication requirements changed
-
-### Environment & Configuration
-
-- New environment variable required but not in CLAUDE.md or deployment docs
-- Configuration option removed but still documented
-- Default value changed for existing config
-
-### Architecture Changes
-
-- New module/app created without corresponding Notion documentation
-- Service dependencies changed (module A now depends on module B, but docs don't show this)
-- Database migration adds/removes tables not reflected in schema docs
-
----
-
-## 🟡 Moderate — Would Miss Important Capabilities
-
-These mismatches would cause someone to miss important features or follow outdated procedures.
-
-### Service Changes
-
-- New service class added to a module but module page doesn't list it in the services section
-- Service method signature changed (different params) but process docs reference old signature
-- Service now calls a different external provider but process diagrams show old flow
-
-**Example:**
-> Code adds `AccessKeyService` to handle crypto signing, but the Crypto module page doesn't list it under Services.
-
-### Process Flow Changes
-
-- Steps in a business process reordered or modified
-- New step added to a process (e.g., new validation step in onboarding)
-- Conditional logic changed (e.g., different handling for B2B vs B2C)
-- Process now has prerequisites that aren't documented
-
-**Example:**
-> Customer onboarding now requires provider-specific KYC before account creation, but the process page still shows a single KYC step.
-
-### Feature Documentation Gaps
-
-- New feature implemented but no feature document exists
-- Feature behavior changed significantly but feature docs describe old behavior
-- Feature flag added without documentation in relevant places
-
-### Workflow Changes
-
-- Webhook handling changed but webhook documentation outdated
-- Background task behavior modified but not reflected in process docs
-- Error handling strategy changed for a module
-
----
-
-## 🟢 Light — Brief Confusion Only
-
-These mismatches would cause someone brief confusion but wouldn't lead to incorrect work.
-
-### Naming/Renaming
-
-- Service or utility class renamed but docs use old name
-- File moved to different directory but docs reference old path
-- Variable or constant renamed
-
-**Example:**
-> `CryptoSigningService` renamed to `AccessKeyService` in code but Notion module page still says `CryptoSigningService`.
-
-### Outdated Examples
-
-- Code example in docs uses old import path
-- Example shows deprecated API usage but functionally equivalent
-- Test examples reference old fixtures
-
-### Minor Wording
-
-- Documentation says "will be implemented" for already-implemented features
-- Status markers (TODO, WIP) left in docs for completed work
-- Comments in code reference old Notion page names
-
----
-
-## Per-Source Analysis Guide
-
-### Notion Module Pages
-
-Module pages describe models and services for each module. When checking:
-
-1. **Models section** — Compare listed models against actual Django models in the code
-2. **Services section** — Compare listed services against actual service classes
-3. **API section** — Compare listed endpoints against actual URL configs
-4. **Shared models** — Verify cross-module dependencies are still accurate
-5. **Dependency graph** — Check if module interdependencies changed
-
-### Notion Processes Database
-
-Process pages describe business workflows. When checking:
-
-1. **Process steps** — Do the documented steps match the actual code flow?
-2. **Prerequisites** — Are process prerequisites still accurate?
-3. **Provider interactions** — Do provider-specific flows match current implementation?
-4. **Status transitions** — Do documented state machines match code?
-5. **Related modules** — Is the "Модули" relation still correct?
-
-### Repository docs/ Directory
-
-Local documentation files. When checking:
-
-1. **Architecture docs** — Do they reflect current module structure?
-2. **API docs** — Do endpoint descriptions match implementations?
-3. **Setup/deployment docs** — Are instructions still accurate?
-
-### CLAUDE.md
-
-Project-level documentation. When checking:
-
-1. **Environment variables table** — All required vars listed?
-2. **Project structure** — Does the tree match actual directory layout?
-3. **Technology stack** — Any new dependencies or tools?
-4. **Key documentation links** — Do referenced docs still exist?
-
-### Database Schema
-
-Schema documentation. When checking:
-
-1. **Table definitions** — Do they match current migrations?
-2. **Relationships** — Are FK/M2M relations documented correctly?
-3. **Indexes** — Any new indexes not mentioned in schema docs?
-4. **New tables** — Any new migrations creating tables not in schema docs?
-
----
-
-## Edge Cases
-
-### When NOT to Flag
-
-- Code comments that are slightly outdated (not worth a Linear comment)
-- Test file documentation being slightly behind (tests are self-documenting)
-- Third-party library version bumps with no behavior change
-- Formatting-only changes to documentation files
-- Internal refactoring that doesn't change public interfaces or behavior
-
-### When to Escalate to Critical
-
-Even if a change seems small, escalate if:
-- It affects an external-facing API that developers build against
-- It changes model fields that other services query
-- It modifies environment variables needed for deployment
-- It alters the behavior described in a process that operations follows
-
-### Multiple Small Issues
-
-If there are many Light issues (5+) concentrated in one documentation area, consider grouping them and elevating to a single Moderate finding with a suggestion to do a documentation review for that area.

package/dist/claude-config/worktrees/valiant-sparking-hare/.github/workflows/claude-code-review.yml

@@ -1,32 +0,0 @@
-name: Claude Code Review
-
-on:
-  pull_request:
-    types: [opened, synchronize, ready_for_review, reopened]
-
-jobs:
-  claude-review:
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write
-      pull-requests: write
-      issues: write
-      id-token: write
-
-    steps:
-      - name: Checkout repository
-        uses: actions/checkout@v4
-        with:
-          fetch-depth: 1
-
-      - name: Run Claude Code Review
-        id: claude-review
-        uses: anthropics/claude-code-action@v1
-        with:
-          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
-          plugin_marketplaces: 'https://github.com/anthropics/claude-code.git'
-          plugins: 'code-review@claude-code-plugins'
-          prompt: '/code-review:code-review ${{ github.repository }}/pull/${{ github.event.pull_request.number }}'
-          # See https://github.com/anthropics/claude-code-action/blob/main/docs/usage.md
-          # or https://code.claude.com/docs/en/cli-reference for available options
-

package/dist/claude-config/worktrees/valiant-sparking-hare/.github/workflows/claude.yml

@@ -1,37 +0,0 @@
-name: Claude Code
-
-on:
-  issue_comment:
-    types: [created]
-  pull_request_review_comment:
-    types: [created]
-  issues:
-    types: [opened, assigned]
-  pull_request_review:
-    types: [submitted]
-
-jobs:
-  claude:
-    if: |
-      (github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude')) ||
-      (github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude')) ||
-      (github.event_name == 'pull_request_review' && contains(github.event.review.body, '@claude')) ||
-      (github.event_name == 'issues' && (contains(github.event.issue.body, '@claude') || contains(github.event.issue.title, '@claude')))
-    runs-on: ubuntu-latest
-    permissions:
-      contents: write
-      pull-requests: write
-      issues: write
-      id-token: write
-      actions: read # Required for Claude to read CI results on PRs
-    steps:
-      - name: Checkout repository
-        uses: actions/checkout@v4
-        with:
-          fetch-depth: 1
-
-      - name: Run Claude Code
-        id: claude
-        uses: anthropics/claude-code-action@v1
-        with:
-          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}

package/dist/claude-config/worktrees/valiant-sparking-hare/.nvmrc

@@ -1 +0,0 @@
-v22.18.0

package/dist/claude-config/worktrees/valiant-sparking-hare/.prettierignore

@@ -1,11 +0,0 @@
-*.yml
-*.yaml
-*.d.ts
-node_modules
-coverage
-.nuxt
-.output
-.npmrc
-.nvmrc
-dist
-public