paput-mcp 4.2.5 → 4.2.7

package/README.md

@@ -121,7 +121,7 @@ npx -y paput-mcp setup-ai --codex-only
 
 Generated skills:
 
-- `paput-init` - Initialize PaPut usage and inspect unprocessed sessions from local-file-capable AI clients.
+- `paput-harvest` - Harvest reusable knowledge from past local sessions in local-file-capable AI clients. Safe to run repeatedly; skips already-processed sessions.
 - `paput-capture` - Extract reusable knowledge candidates from the current conversation or a specified topic and add them to pending.
 - `paput-save` - Review pending candidates first, then save only candidates explicitly approved by the user.
 - `paput-analyze-discard-policy` - Analyze discarded candidates and save a capture policy used by future captures.
@@ -268,7 +268,8 @@ Remote HTTP MCP.
 
 PaPut MCP no longer reads local Claude/Codex session files as MCP tools. When
 using Claude Code, Codex, or another AI client with local file access, run the
-installed `paput-init` skill. The AI client reads its own session files, extracts
+installed `paput-harvest` skill (safe to run repeatedly; it skips
+already-processed sessions). The AI client reads its own session files, extracts
 reusable knowledge, and submits only the resulting candidates and processed
 session markers through PaPut MCP.
 

package/dist/cli/skills/paput-capture/SKILL.md

@@ -53,6 +53,7 @@ Guidance:
 
 - Capture candidates are reusable decision criteria, procedures, or principles, so prefer `decision` / `operation` / `principle` when they fit; use `knowledge` for commodity technical know-how.
 - `decision` / `operation` / `principle` are the primary material for the public AI summary; `knowledge` usually is not.
+- AI-collaboration practices and stances belong here, not in the reject pile: how you structure a task or spec for an AI, your review discipline for AI-generated changes, where you verify versus trust AI output, when you delegate versus do it yourself. Capture the reusable practice as `operation` or the stated stance as `principle` — generalized so it would hold with a different AI tool, on a different project, for someone else to learn. This is the scarcest, most durable axis; do not drop it as workflow chatter.
 - Leaving a candidate unclassified (no type) is allowed, but classifying it improves analysis and the public profile. Do not force a type when none fits.
 
 ## Quality Bar
@@ -73,7 +74,7 @@ Prefer generalized but concrete writing:
 Do not add these to pending:
 
 - Project-specific specifications, screen names, button names, business workflows, operational rules, or local context.
-- Personal workflow notes about PRs, GitHub, Codex, Claude, AI review, editors, or OS operations.
+- One-off tool mechanics or configuration: editor / OS / CLI settings, keybindings, which button was clicked, model- or version-specific quirks, project-specific CI wiring, or anecdotes about a single session (for example, "the AI got confused here"). These are commodity even when they mention AI tools — capture the reusable practice or stance instead, not the mechanics. Reusable AI-collaboration practices and stances ARE worth capturing (see the AI-collaboration note under Memo Type); do not discard them as workflow chatter.
 - Content that third parties cannot understand from the title and body alone.
 - Rejected designs, anecdotes, work logs, impressions, or decision histories without reusable guidance.
 - Content semantically close to existing memos or pending candidates.

package/dist/cli/skills/paput-dashboard-analysis/SKILL.md

@@ -9,6 +9,8 @@ Analyze the user's PaPut dashboard and goals. Use this skill when the user asks
 
 Read the user through the JUDGMENT axis, not raw volume. The durable, hard-to-commoditize part of what they accumulate is their judgment and practice — captured as `memo_type`: `decision` (judgment criteria), `operation` (operating practices), `principle` (stated stances). `knowledge` is commodity. `structuredContent.dashboard_summary.memo_type_counts` holds the per-type accumulation; assess the user by how thick those three durable axes are, with categories as a secondary lens for the domains they work in.
 
+The judgment axis is the LENS, not a replacement for goal analysis. The dashboard's core job is "where am I against my goals", so keep goals first-class: read each active goal THROUGH the axis — which judgment/practice/principle axis that goal requires, and whether that axis is currently thick or thin. Do not drop the goal overview in favor of axis-only talk.
+
 ## Workflow
 
 1. Call `paput_get_dashboard_analysis_context`.
@@ -21,12 +23,12 @@ Read the user through the JUDGMENT axis, not raw volume. The durable, hard-to-co
 
 Include these points when relevant, read through the decision / operation / principle axes:
 
-- Current position — which judgment axes are thick, which are thin (from `memo_type_counts`).
+- Current position — which judgment axes are thick, which are thin (from `memo_type_counts`), AND a goal overview: name the active goals and, for each, the judgment/practice/principle axis it requires and whether that axis is currently thick or thin. The `current_summary` must keep this goal overview, not just axis talk.
 - Strengths — the judgment criteria and operating practices the user has accumulated (decision / operation / principle), with the domains (categories) they show up in as supporting context. knowledge alone is not a strength.
 - Areas that have been growing recently.
 - Thin or underdeveloped axes — name the thin memo_type (e.g. principle is thin) and what that means, not just thin categories.
-- Knowledge missing against active goals.
-- What to do next to thicken the thin durable axis (e.g. distill recurring decisions into principles, capture operating practices / eval / review as operation), rather than just "learn more".
+- Gaps against active goals — for each active goal, the judgment axis it needs that is still thin (e.g. "G2 needs principle, which is the thinnest axis"). This is the goal-alignment view; tie it to `goal_ids`.
+- What to do next to thicken the thin durable axis the goals require (e.g. distill recurring decisions into principles, capture operating practices / eval / review as operation), rather than just "learn more". Link each suggestion to the goal it serves via `goal_ids`.
 - Phrasing suitable for a skill sheet or career history.
 
 ## Rules
@@ -36,10 +38,11 @@ Include these points when relevant, read through the decision / operation / prin
 - Treat archived goals as historical context.
 - Do not recalculate dashboard continuity from activities. Use the dashboard summary values returned by the API.
 - Frame current position, strengths, and thin areas by decision / operation / principle thickness — not by how many memos or categories accumulated. Use categories as a secondary lens for the domains, not the main axis.
+- Keep goals first-class. The `current_summary` must include a goal overview (the active goals, and for each the judgment axis it requires and whether it is thick or thin). At least one `weak_areas` item and the `next_knowledge_suggestions` must connect a thin axis to the goal it blocks, via `goal_ids`. The axis is the lens for goal alignment, not a replacement for it.
 - `knowledge`-type memos are commodity. Do not present knowledge volume as a strength on its own.
 - When the thin axis is `principle` or `operation`, say so plainly and make the next step about thickening it (distilling decisions into principles, capturing eval / observability / review as operation).
 - In each saved item's `description`, speak in the judgment/practice/principle axis (which memo_type backs the strength, which type is thin). The output fields are unchanged; the axis is carried in the wording.
-- `category_names` must be EXACT names the user actually uses — take them from `structuredContent.dashboard_summary.category_item_counts` (the user's own categories), falling back to `structuredContent.categories` (the global list) only for exact spelling. Do not invent, translate, or paraphrase category names (e.g. do not write "可観測性" or "CI/開発基盤" if they are not in those lists). If no listed category matches the item, leave `category_names` empty — categories are a secondary lens, so an empty list is fine and better than an approximate name.
+- `category_names` must be EXACT names the user actually uses — take them from `structuredContent.dashboard_summary.category_item_counts` (the user's own categories), falling back to `structuredContent.categories` (the global list) only for exact spelling. DO populate them with the real categories that genuinely apply to the item (e.g. a deployment/observability strength should list the user's actual categories like Datadog / OpenSearch / ECS when present) — do not default to empty when real matches exist. Only leave `category_names` empty when none of the user's categories match. Never invent, translate, or paraphrase a category name (e.g. do not write "可観測性" or "CI/開発基盤" if they are not in those lists); an empty list is better than an approximate name.
 - When saving, map the generated result to:
   - `current_summary`
   - `strengths`

package/dist/cli/skills/{paput-init → paput-harvest}/SKILL.md

@@ -1,16 +1,21 @@
 ---
-name: paput-init
-description: Use this to initialize PaPut usage and inspect unprocessed local Claude/Codex sessions when the AI client can read local files.
+name: paput-harvest
+description: Use this to harvest reusable knowledge from past local Claude/Codex sessions when the AI client can read local files. Safe to run repeatedly — it skips already-processed sessions and only reviews new ones — so use it both for first-time onboarding and for periodic catch-up. Pay special attention to AI-collaboration practices and stances (operation / principle), the scarce, durable axis.
 ---
 
-# PaPut Init
+# PaPut Harvest
 
-Initialize PaPut knowledge capture from past local AI sessions.
+Harvest reusable knowledge from past local AI sessions into pending candidates.
 
 This skill is for local-file-capable AI clients such as Claude Code or Codex.
-PaPut MCP does not read local session files. The AI client should read the
-session files directly, then use PaPut MCP only to check processed-session
-markers and add or mark reviewed sessions.
+PaPut MCP does not read local session files. The AI client reads the session
+files directly, then uses PaPut MCP only to check processed-session markers and
+add or mark reviewed sessions.
+
+Run it whenever you want — it is idempotent. It checks which sessions are already
+processed and reviews only the new ones, so the first run doubles as onboarding
+(nothing is processed yet, so it surveys your history) and later runs are
+periodic catch-up. There is no separate "init" step.
 
 ## Steps
 
@@ -26,6 +31,9 @@ markers and add or mark reviewed sessions.
 5. Report the count and a short summary of unprocessed sessions to the user.
 6. Only when the user wants it, read the relevant session transcript directly
    from the JSONL file and create candidates that meet the extraction criteria.
+   While reading, actively look for the AI-collaboration axis (see Extraction
+   Criteria) in addition to ordinary technical knowledge — it is easy to miss
+   because it shows up as how the work was directed, not as the work itself.
 7. Before adding candidates with `paput_add_knowledge_candidates`, check that
    they do not contain project-specific specifications, implementation details,
    operational rules, code, customer data, or secrets. Duplicate checks against
@@ -33,6 +41,8 @@ markers and add or mark reviewed sessions.
    using semantic search.
 8. If reusable candidates exist, call `paput_add_knowledge_candidates` with
    `source`, `session_id`, `source_session_updated_at`, and the candidates.
+   Set `memo_type_keys` on each candidate (see Memo Type below); classify
+   AI-collaboration practices as `operation` and stances as `principle`.
 9. If the session was reviewed but no candidates should be added, call
    `paput_mark_processed_session` with `source`, `session_id`, and
    `source_session_updated_at`.
@@ -67,10 +77,27 @@ tail sections first, then ask before reading more.
 
 Only add technical knowledge, decision criteria, and procedures that can be reused in other projects.
 
-Do not add these to pending:
+### Capture the AI-collaboration axis
+
+Reusable AI-collaboration practices and stances are first-class material here —
+they are the scarcest, most durable axis and are easy to discard by mistake.
+Capture them as `operation` (practice) or `principle` (stance). Examples:
+
+- How you structure a task or spec so an AI implements it correctly.
+- Your review discipline for AI-generated changes — where you always verify
+  versus where you trust the output.
+- When you delegate to an AI versus do it yourself.
+- How you decompose work for parallel agents, or recover when an AI goes wrong.
+
+The test: would this still hold with a different AI tool, on a different
+project, for someone else to learn? If yes, capture it as `operation` or
+`principle`, generalized one level above the specific session. If it is only
+about this tool's mechanics or this one session's events, exclude it.
+
+### Do not add these to pending
 
 - Project-specific specifications, screen names, button names, business workflows, operational rules, or local context.
-- Personal workflow notes about PRs, GitHub, Codex, Claude, AI review, editors, or OS operations.
+- One-off tool mechanics or configuration: editor / OS / CLI settings, keybindings, which button was clicked, model- or version-specific quirks, project-specific CI wiring, or anecdotes about a single session (for example, "the AI got confused here"). These are commodity even when they mention AI tools — capture the reusable practice or stance instead, not the mechanics.
 - Content that third parties cannot understand from the title and body alone.
 - Rejected designs, anecdotes, work logs, impressions, or decision histories without reusable guidance.
 - Content semantically close to existing memos or pending candidates.
@@ -79,6 +106,19 @@ Do not add these to pending:
 
 When unsure, do not add the candidate. Report that there is no knowledge to save or that the candidate was rejected.
 
+## Memo Type
+
+Classify each candidate with one or more memo types via `memo_type_keys`:
+
+- `decision`: reusable judgment criteria independent of any project.
+- `operation`: operating practices — observability, eval, testing, review, and how you direct and verify AI collaboration.
+- `principle`: a stance you have explicitly stated, generalized above individual decisions, including stances on how to work with AI.
+- `knowledge`: commodity technical know-how, usage, or implementation knowledge.
+
+`decision` / `operation` / `principle` are the primary material for the public
+AI summary and the principle synthesizer; `knowledge` usually is not. Prefer the
+durable types when they fit, and do not force a type when none does.
+
 ## Notes
 
 - Do not save directly to PaPut.

package/dist/handlers/get-dashboard-analysis-context/handler.js

@@ -97,6 +97,8 @@ function buildPrompt(context) {
 
 Lead with the judgment axis, not raw volume. The durable, hard-to-commoditize part of what the user accumulates is their JUDGMENT and PRACTICE — captured as memo_type: decision (judgment criteria), operation (operating practices: observability, eval, testing, review), and principle (stated stances). knowledge is commodity. So assess the user by how thick those three axes are, not by how many memos or categories they have. structuredContent.dashboard_summary.memo_type_counts holds the per-type accumulation.
 
+The judgment axis is the LENS, not a replacement for goal analysis. The dashboard's core job is "where am I against my goals", so keep goals first-class: read each active goal THROUGH the axis — which judgment/practice/principle axis that goal requires, and whether it is currently thick or thin. Do not drop the goal overview in favor of axis-only talk.
+
 Assumptions:
 - Do not recalculate dashboard continuity from activities. Use the summary values returned by the API.
 - Treat active goals as the current basis for analysis and archived goals as historical context.
@@ -118,15 +120,15 @@ Context summary:
 - Saved analysis: ${context.hasSavedAnalysis ? 'available' : 'not available'}
 
 Include these analysis points:
-1. The user's current position, read through the judgment/practice/principle axes (which axes are thick, which are thin).
+1. The user's current position, read through the judgment/practice/principle axes (which axes are thick, which are thin), AND a goal overview: name the active goals and, for each, the axis it requires and whether that axis is thick or thin. The current_summary must keep this goal overview, not just axis talk.
 2. Strengths — the judgment criteria and operating practices the user has accumulated (decision / operation / principle), with the domains (categories) they show up in as supporting context.
 3. Areas that have been growing recently.
 4. Thin or underdeveloped axes — name the memo_type that is thin (e.g. principle is thin) and what that means, not just thin categories.
-5. Knowledge missing against the user's goals.
-6. What to do next to thicken the thin durable axis (e.g. distill recurring decisions into principles, capture operating practices), rather than just "learn more".
+5. Gaps against active goals — for each active goal, the judgment axis it needs that is still thin (e.g. "G2 needs principle, which is the thinnest axis"). This is the goal-alignment view; connect it to goal_ids.
+6. What to do next to thicken the thin durable axis the goals require (e.g. distill recurring decisions into principles, capture operating practices), rather than just "learn more". Link each suggestion to the goal it serves via goal_ids.
 7. Phrasing that can be used in a skill sheet or career history.
 
 If saving the result, build values suitable for paput_update_dashboard_analysis: current_summary, strengths, growing_areas, weak_areas, next_knowledge_suggestions, and analyzed_at. strengths, growing_areas, and weak_areas should include title, description, category_names, memo_count, and goal_ids — and in each description speak in the judgment/practice/principle axis (e.g. which memo_type backs the strength, which type is thin). next_knowledge_suggestions should include title, reason, priority, category_names, and goal_ids.
-category_names must be EXACT names the user actually uses — take them from structuredContent.dashboard_summary.category_item_counts (the user's own categories), falling back to structuredContent.categories (the global list) only for exact spelling. Do not invent, translate, or paraphrase category names. If no listed category matches the item, leave category_names empty; categories are a secondary lens, so an empty list is better than an approximate name.`;
+category_names must be EXACT names the user actually uses — take them from structuredContent.dashboard_summary.category_item_counts (the user's own categories), falling back to structuredContent.categories (the global list) only for exact spelling. DO populate them with the real categories that genuinely apply to the item (e.g. a deployment/observability strength should list the user's actual categories like Datadog / OpenSearch / ECS when present); do not default to empty when real matches exist. Only leave category_names empty when none of the user's categories match. Never invent, translate, or paraphrase a category name; an empty list is better than an approximate name.`;
 }
 //# sourceMappingURL=handler.js.map

package/dist/handlers/get-dashboard-analysis-context/handler.js.map

@@ -1 +1 @@
-{"version":3,"file":"handler.js","sourceRoot":"","sources":["../../../src/handlers/get-dashboard-analysis-context/handler.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,aAAa,EAAE,MAAM,gCAAgC,CAAC;AAC/D,OAAO,EAAE,mBAAmB,EAAE,MAAM,iCAAiC,CAAC;AACtE,OAAO,EAAE,oBAAoB,EAAE,MAAM,0CAA0C,CAAC;AAChF,OAAO,EAAE,SAAS,EAAE,MAAM,4BAA4B,CAAC;AACvD,OAAO,EAAE,WAAW,EAAE,MAAM,4BAA4B,CAAC;AACzD,OAAO,EAAE,WAAW,EAAE,MAAM,4BAA4B,CAAC;AACzD,OAAO,EAAE,aAAa,EAAE,MAAM,mCAAmC,CAAC;AAElE,MAAM,iBAAiB,GAAG,EAAE,CAAC;AAE7B,MAAM,CAAC,KAAK,UAAU,iCAAiC,CACrD,KAA0C,EAC1C,SAAoB;IAEpB,IAAI,CAAC;QACH,MAAM,CAAC,gBAAgB,EAAE,KAAK,CAAC,GAAG,MAAM,OAAO,CAAC,GAAG,CAAC;YAClD,mBAAmB,CAAC,SAAS,CAAC;YAC9B,SAAS,CAAC,SAAS,CAAC;SACrB,CAAC,CAAC;QAEH,MAAM,CACJ,UAAU,EACV,iBAAiB,EACjB,WAAW,EACX,UAAU,EACV,aAAa,EACd,GAAG,MAAM,OAAO,CAAC,GAAG,CAAC;YACpB,SAAS,CAAC,GAAG,EAAE,CAAC,aAAa,CAAC,SAAS,CAAC,CAAC;YACzC,SAAS,CAAC,GAAG,EAAE,CACb,WAAW,CAAC,SAAS,EAAE;gBACrB,IAAI,EAAE,CAAC;gBACP,KAAK,EAAE,iBAAiB;aACzB,CAAC,CACH;YACD,SAAS,CAAC,GAAG,EAAE,CACb,WAAW,CAAC,SAAS,EAAE;gBACrB,IAAI,EAAE,CAAC;gBACP,KAAK,EAAE,iBAAiB;aACzB,CAAC,CACH;YACD,SAAS,CAAC,GAAG,EAAE,CAAC,aAAa,CAAC,SAAS,CAAC,CAAC;YACzC,SAAS,CAAC,GAAG,EAAE,CAAC,oBAAoB,CAAC,SAAS,CAAC,CAAC;SACjD,CAAC,CAAC;QAEH,MAAM,WAAW,GACf,iBAAiB,IAAI,iBAAiB,CAAC,OAAO;YAC5C,CAAC,CAAC,iBAAiB,CAAC,KAAK,IAAI,EAAE;YAC/B,CAAC,CAAC,EAAE,CAAC;QACT,MAAM,KAAK,GACT,WAAW,IAAI,WAAW,CAAC,OAAO,CAAC,CAAC,CAAC,WAAW,CAAC,KAAK,IAAI,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;QACpE,MAAM,MAAM,GAAG,WAAW,CAAC;YACzB,gBAAgB;YAChB,KAAK;YACL,cAAc,EAAE,gBAAgB,CAAC,gBAAgB,IAAI,EAAE;YACvD,eAAe,EAAE,WAAW,CAAC,MAAM;YACnC,SAAS,EAAE,KAAK,CAAC,MAAM;YACvB,aAAa,EAAE,UAAU,EAAE,MAAM,IAAI,CAAC;YACtC,aAAa,EAAE,OAAO,CAAC,UAAU,CAAC;YAClC,gBAAgB,EAAE,OAAO,CAAC,aAAa,CAAC;SACzC,CAAC,CAAC;QAEH,OAAO;YACL,iBAAiB,EAAE;gBACjB,iBAAiB,EAAE,gBAAgB;gBACnC,KAAK;gBACL,WAAW,EAAE,UAAU;gBACvB,YAAY,EAAE,WAAW;gBACzB,KAAK;gBACL,UAAU,EAAE,UAAU,IAAI,EAAE;gBAC5B,wBAAwB,EAAE,aAAa;gBACvC,MAAM;aACP;YACD,OAAO,EAAE;gBACP;oBACE,IAAI,EAAE,MAAM;oBACZ,IAAI,EAAE;iCACiB,gBAAgB,CAAC,gBAAgB,iBAAiB,gBAAgB,CAAC,gBAAgB,kBAAkB,gBAAgB,CAAC,iBAAiB,iCAAiC,gBAAgB,CAAC,2BAA2B;SAC5O,KAAK,CAAC,MAAM;eACN,UAAU,CAAC,CAAC,CAAC,WAAW,CAAC,CAAC,CAAC,eAAe;gBACzC,WAAW,CAAC,MAAM;SACzB,KAAK,CAAC,MAAM;cACP,UAAU,EAAE,MAAM,IAAI,CAAC;4BACT,aAAa,CAAC,CAAC,CAAC,WAAW,CAAC,CAAC,CAAC,eAAe;;EAEvE,MAAM,EAAE;iBACD;aACF;SACF,CAAC;IACJ,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QACf,MAAM,YAAY,GAChB,KAAK,YAAY,KAAK,CAAC,CAAC,CAAC,KAAK,CAAC,OAAO,CAAC,CAAC,CAAC,eAAe,CAAC;QAE3D,OAAO;YACL,OAAO,EAAE;gBACP;oBACE,IAAI,EAAE,MAAM;oBACZ,IAAI,EAAE,oDAAoD,YAAY,EAAE;iBACzE;aACF;YACD,OAAO,EAAE,IAAI;SACd,CAAC;IACJ,CAAC;AACH,CAAC;AAED,KAAK,UAAU,SAAS,CAAI,OAAyB;IACnD,IAAI,CAAC;QACH,OAAO,MAAM,OAAO,EAAE,CAAC;IACzB,CAAC;IAAC,MAAM,CAAC;QACP,OAAO,IAAI,CAAC;IACd,CAAC;AACH,CAAC;AAED,SAAS,WAAW,CAAC,OAcpB;IACC,MAAM,WAAW,GAAG,OAAO,CAAC,KAAK,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,MAAM,KAAK,QAAQ,CAAC,CAAC;IAC7E,MAAM,aAAa,GAAG,OAAO,CAAC,KAAK,CAAC,MAAM,CACxC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,MAAM,KAAK,UAAU,CACrC,CAAC;IAEF,MAAM,OAAO,GAAG,CAAC,GAAW,EAAU,EAAE,CACtC,OAAO,CAAC,cAAc,CAAC,IAAI,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,GAAG,KAAK,GAAG,CAAC,EAAE,KAAK,IAAI,CAAC,CAAC;IACxE,MAAM,YAAY,GAAG,YAAY,OAAO,CAAC,UAAU,CAAC,eAAe,OAAO,CAAC,WAAW,CAAC,eAAe,OAAO,CAAC,WAAW,CAAC,eAAe,OAAO,CAAC,WAAW,CAAC,EAAE,CAAC;IAEhK,OAAO;;;;;;;;;;;4CAWmC,YAAY;sBAClC,OAAO,CAAC,gBAAgB,CAAC,gBAAgB;sBACzC,OAAO,CAAC,gBAAgB,CAAC,gBAAgB;uBACxC,OAAO,CAAC,gBAAgB,CAAC,iBAAiB;qCAC5B,OAAO,CAAC,gBAAgB,CAAC,2BAA2B;kBACvE,WAAW,CAAC,MAAM;oBAChB,aAAa,CAAC,MAAM;4BACZ,OAAO,CAAC,eAAe;qBAC9B,OAAO,CAAC,SAAS;0BACZ,OAAO,CAAC,aAAa;iBAC9B,OAAO,CAAC,aAAa,CAAC,CAAC,CAAC,WAAW,CAAC,CAAC,CAAC,eAAe;oBAClD,OAAO,CAAC,gBAAgB,CAAC,CAAC,CAAC,WAAW,CAAC,CAAC,CAAC,eAAe;;;;;;;;;;;;2cAY+X,CAAC;AAC5c,CAAC"}
+{"version":3,"file":"handler.js","sourceRoot":"","sources":["../../../src/handlers/get-dashboard-analysis-context/handler.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,aAAa,EAAE,MAAM,gCAAgC,CAAC;AAC/D,OAAO,EAAE,mBAAmB,EAAE,MAAM,iCAAiC,CAAC;AACtE,OAAO,EAAE,oBAAoB,EAAE,MAAM,0CAA0C,CAAC;AAChF,OAAO,EAAE,SAAS,EAAE,MAAM,4BAA4B,CAAC;AACvD,OAAO,EAAE,WAAW,EAAE,MAAM,4BAA4B,CAAC;AACzD,OAAO,EAAE,WAAW,EAAE,MAAM,4BAA4B,CAAC;AACzD,OAAO,EAAE,aAAa,EAAE,MAAM,mCAAmC,CAAC;AAElE,MAAM,iBAAiB,GAAG,EAAE,CAAC;AAE7B,MAAM,CAAC,KAAK,UAAU,iCAAiC,CACrD,KAA0C,EAC1C,SAAoB;IAEpB,IAAI,CAAC;QACH,MAAM,CAAC,gBAAgB,EAAE,KAAK,CAAC,GAAG,MAAM,OAAO,CAAC,GAAG,CAAC;YAClD,mBAAmB,CAAC,SAAS,CAAC;YAC9B,SAAS,CAAC,SAAS,CAAC;SACrB,CAAC,CAAC;QAEH,MAAM,CACJ,UAAU,EACV,iBAAiB,EACjB,WAAW,EACX,UAAU,EACV,aAAa,EACd,GAAG,MAAM,OAAO,CAAC,GAAG,CAAC;YACpB,SAAS,CAAC,GAAG,EAAE,CAAC,aAAa,CAAC,SAAS,CAAC,CAAC;YACzC,SAAS,CAAC,GAAG,EAAE,CACb,WAAW,CAAC,SAAS,EAAE;gBACrB,IAAI,EAAE,CAAC;gBACP,KAAK,EAAE,iBAAiB;aACzB,CAAC,CACH;YACD,SAAS,CAAC,GAAG,EAAE,CACb,WAAW,CAAC,SAAS,EAAE;gBACrB,IAAI,EAAE,CAAC;gBACP,KAAK,EAAE,iBAAiB;aACzB,CAAC,CACH;YACD,SAAS,CAAC,GAAG,EAAE,CAAC,aAAa,CAAC,SAAS,CAAC,CAAC;YACzC,SAAS,CAAC,GAAG,EAAE,CAAC,oBAAoB,CAAC,SAAS,CAAC,CAAC;SACjD,CAAC,CAAC;QAEH,MAAM,WAAW,GACf,iBAAiB,IAAI,iBAAiB,CAAC,OAAO;YAC5C,CAAC,CAAC,iBAAiB,CAAC,KAAK,IAAI,EAAE;YAC/B,CAAC,CAAC,EAAE,CAAC;QACT,MAAM,KAAK,GACT,WAAW,IAAI,WAAW,CAAC,OAAO,CAAC,CAAC,CAAC,WAAW,CAAC,KAAK,IAAI,EAAE,CAAC,CAAC,CAAC,EAAE,CAAC;QACpE,MAAM,MAAM,GAAG,WAAW,CAAC;YACzB,gBAAgB;YAChB,KAAK;YACL,cAAc,EAAE,gBAAgB,CAAC,gBAAgB,IAAI,EAAE;YACvD,eAAe,EAAE,WAAW,CAAC,MAAM;YACnC,SAAS,EAAE,KAAK,CAAC,MAAM;YACvB,aAAa,EAAE,UAAU,EAAE,MAAM,IAAI,CAAC;YACtC,aAAa,EAAE,OAAO,CAAC,UAAU,CAAC;YAClC,gBAAgB,EAAE,OAAO,CAAC,aAAa,CAAC;SACzC,CAAC,CAAC;QAEH,OAAO;YACL,iBAAiB,EAAE;gBACjB,iBAAiB,EAAE,gBAAgB;gBACnC,KAAK;gBACL,WAAW,EAAE,UAAU;gBACvB,YAAY,EAAE,WAAW;gBACzB,KAAK;gBACL,UAAU,EAAE,UAAU,IAAI,EAAE;gBAC5B,wBAAwB,EAAE,aAAa;gBACvC,MAAM;aACP;YACD,OAAO,EAAE;gBACP;oBACE,IAAI,EAAE,MAAM;oBACZ,IAAI,EAAE;iCACiB,gBAAgB,CAAC,gBAAgB,iBAAiB,gBAAgB,CAAC,gBAAgB,kBAAkB,gBAAgB,CAAC,iBAAiB,iCAAiC,gBAAgB,CAAC,2BAA2B;SAC5O,KAAK,CAAC,MAAM;eACN,UAAU,CAAC,CAAC,CAAC,WAAW,CAAC,CAAC,CAAC,eAAe;gBACzC,WAAW,CAAC,MAAM;SACzB,KAAK,CAAC,MAAM;cACP,UAAU,EAAE,MAAM,IAAI,CAAC;4BACT,aAAa,CAAC,CAAC,CAAC,WAAW,CAAC,CAAC,CAAC,eAAe;;EAEvE,MAAM,EAAE;iBACD;aACF;SACF,CAAC;IACJ,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QACf,MAAM,YAAY,GAChB,KAAK,YAAY,KAAK,CAAC,CAAC,CAAC,KAAK,CAAC,OAAO,CAAC,CAAC,CAAC,eAAe,CAAC;QAE3D,OAAO;YACL,OAAO,EAAE;gBACP;oBACE,IAAI,EAAE,MAAM;oBACZ,IAAI,EAAE,oDAAoD,YAAY,EAAE;iBACzE;aACF;YACD,OAAO,EAAE,IAAI;SACd,CAAC;IACJ,CAAC;AACH,CAAC;AAED,KAAK,UAAU,SAAS,CAAI,OAAyB;IACnD,IAAI,CAAC;QACH,OAAO,MAAM,OAAO,EAAE,CAAC;IACzB,CAAC;IAAC,MAAM,CAAC;QACP,OAAO,IAAI,CAAC;IACd,CAAC;AACH,CAAC;AAED,SAAS,WAAW,CAAC,OAcpB;IACC,MAAM,WAAW,GAAG,OAAO,CAAC,KAAK,CAAC,MAAM,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,MAAM,KAAK,QAAQ,CAAC,CAAC;IAC7E,MAAM,aAAa,GAAG,OAAO,CAAC,KAAK,CAAC,MAAM,CACxC,CAAC,IAAI,EAAE,EAAE,CAAC,IAAI,CAAC,MAAM,KAAK,UAAU,CACrC,CAAC;IAEF,MAAM,OAAO,GAAG,CAAC,GAAW,EAAU,EAAE,CACtC,OAAO,CAAC,cAAc,CAAC,IAAI,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,GAAG,KAAK,GAAG,CAAC,EAAE,KAAK,IAAI,CAAC,CAAC;IACxE,MAAM,YAAY,GAAG,YAAY,OAAO,CAAC,UAAU,CAAC,eAAe,OAAO,CAAC,WAAW,CAAC,eAAe,OAAO,CAAC,WAAW,CAAC,eAAe,OAAO,CAAC,WAAW,CAAC,EAAE,CAAC;IAEhK,OAAO;;;;;;;;;;;;;4CAamC,YAAY;sBAClC,OAAO,CAAC,gBAAgB,CAAC,gBAAgB;sBACzC,OAAO,CAAC,gBAAgB,CAAC,gBAAgB;uBACxC,OAAO,CAAC,gBAAgB,CAAC,iBAAiB;qCAC5B,OAAO,CAAC,gBAAgB,CAAC,2BAA2B;kBACvE,WAAW,CAAC,MAAM;oBAChB,aAAa,CAAC,MAAM;4BACZ,OAAO,CAAC,eAAe;qBAC9B,OAAO,CAAC,SAAS;0BACZ,OAAO,CAAC,aAAa;iBAC9B,OAAO,CAAC,aAAa,CAAC,CAAC,CAAC,WAAW,CAAC,CAAC,CAAC,eAAe;oBAClD,OAAO,CAAC,gBAAgB,CAAC,CAAC,CAAC,WAAW,CAAC,CAAC,CAAC,eAAe;;;;;;;;;;;;2qBAY+lB,CAAC;AAC5qB,CAAC"}

package/docs/privacy-policy.md

@@ -39,7 +39,7 @@ Remote MCP connections use OAuth. PaPut issues tokens after you sign in and appr
 Pending candidates, discarded candidate metadata, processed AI session markers,
 and capture policies are stored in PaPut API storage, not under `~/.paput`.
 PaPut MCP does not read local Claude/Codex session files. When you use
-`paput-init` in a local-file-capable client such as Claude Code or Codex, that
+`paput-harvest` in a local-file-capable client such as Claude Code or Codex, that
 client may read its own session files and submit only extracted candidates or
 processed-session markers to PaPut MCP.
 

package/docs/tools.md

@@ -5,8 +5,8 @@ PaPut MCP is a data-only MCP server. It exposes tools and resources for PaPut da
 Remote HTTP mode exposes API-backed PaPut tools. Pending candidates, processed
 session markers, and capture policies are stored by the PaPut API. PaPut MCP
 does not expose tools that read local Claude/Codex session files; local-file-
-capable clients can read those files themselves through the `paput-init` skill
-workflow and then submit extracted candidates through MCP.
+capable clients can read those files themselves through the `paput-harvest`
+skill workflow and then submit extracted candidates through MCP.
 
 ## Confirmation Policy
 
@@ -184,5 +184,5 @@ The capture policy is not saved as a PaPut memo. It is stored by the PaPut API
 and is available through Remote HTTP MCP.
 
 For past-session import, a local-file-capable AI client should read its own
-Claude/Codex session files through the `paput-init` skill, then call
+Claude/Codex session files through the `paput-harvest` skill, then call
 `paput_add_knowledge_candidates` or `paput_mark_processed_session`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "paput-mcp",
-  "version": "4.2.5",
+  "version": "4.2.7",
   "description": "PaPut MCP Server",
   "main": "dist/index.js",
   "type": "module",