paput-mcp 4.2.10 → 4.2.11

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

@@ -42,7 +42,7 @@ Include these points when relevant, read through the decision / operation / prin
 - `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 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.
+- `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 a translated or made-up label like "Observability" or "CI/Build Infrastructure" when that exact string is 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-principle-synthesizer/SKILL.md

@@ -22,7 +22,7 @@ Use this when the user wants to thicken their `principle` memos, distill recurri
    - Make the clusters DISJOINT: assign each source memo to the ONE principle it best anchors, not to several. If two themes overlap heavily or keep pulling the same memos, treat them as ONE cluster, or draw a sharp line so each cluster owns a distinct slice.
 4. Synthesize each qualifying cluster into one `principle` candidate:
    - One cluster → one coherent stance with a SINGLE throughline (one "optimize X over Y"). Every sub-point in the body must be a facet of that one posture. If you find yourself writing "and also…" about a different concern, that is a second principle — split it out or drop the weaker thread. Do not bundle two or three loosely-related ideas under an umbrella title.
-   - body: the stance generalized one level up — what it optimizes for and what it rejects — plus applicability conditions / exceptions where useful, and a `## 根拠` section listing the source memo ids and titles it was synthesized from (reference design docs abstractly, without project-specific leaks).
+   - body: the stance generalized one level up — what it optimizes for and what it rejects — plus applicability conditions / exceptions where useful, and a sources section (use the user's language for the heading) listing the source memo ids and titles it was synthesized from (reference design docs abstractly, without project-specific leaks).
    - Strip project-specific names, screens, code, and secrets; rewrite as reusable judgment criteria (follow the capture policy's generalization rules — fetch it with `paput_get_capture_policy`).
    - Default `is_public: false`; set `memo_type_keys: ['principle']` (add `decision` as a second label only if it is genuinely also a reusable judgment criterion).
 5. Self-review the draft set for MUTUAL distinctness before de-dup:
@@ -41,8 +41,8 @@ Use this when the user wants to thicken their `principle` memos, distill recurri
 - One principle = one throughline. The title must name ONE posture, not an umbrella over several. If the body covers two or three loosely-related concerns, it is a grab-bag — split it into separate principles or drop the weakest thread. Test: can you state it as a single "optimize X, reject Y"? If you need "and also…" about an unrelated concern, it is two principles.
 - Make principles mutually distinct. Do NOT emit two candidates that share most of their source memos or whose statements overlap. When that happens, merge them, or assign each shared memo to the single principle it best anchors and keep the two scopes disjoint. A source memo should anchor one principle, not back two.
 - Cover the corpus. Surface EVERY distinct cross-cutting stance the material supports, not just the first few strong clusters. The disjointness and merge rules reduce duplicates WITHIN a theme; they must not reduce the number of themes. Watch for the scarce, high-value axes that are easy to skip once the security / concurrency clusters are formed — AI / automation collaboration stances, operating practices (observability, eval, testing), and reversibility / incremental change. If the corpus clearly supports such a stance and no candidate covers it, that is under-coverage — add it.
-- Example — grab-bag (avoid): "変更は可逆・最小範囲から段階的に進め、消費側が実在するまで第一級化を急がず、未成熟な依存のために公式推奨を歪めない" bundles three concerns. Split: (1) reversible/incremental change, (2) defer first-classing until a consumer exists. Drop the unrelated "公式推奨を歪めない" to its own memo.
-- Example — overlap (avoid): one principle about "目的ごとに取得経路を分ける" and another about "AI 判定は soft signal" both leaning on the same memos. Keep route-separation in the first and move all AI-judgment material to the second so neither bleeds.
+- Example — grab-bag (avoid): "Advance changes reversibly and in minimal scope, don't rush first-classing until a consumer actually exists, and don't distort the official recommendation for the sake of an immature dependency" bundles three concerns. Split: (1) reversible/incremental change, (2) defer first-classing until a consumer exists. Drop the unrelated "don't distort the official recommendation" to its own memo.
+- Example — overlap (avoid): one principle about "separating retrieval routes by purpose" and another about "AI judgments as soft signals" both leaning on the same memos. Keep route-separation in the first and move all AI-judgment material to the second so neither bleeds.
 - Generalize. Remove project-specific specifications, screen names, code, identifiers, and secrets. The body must be reusable in another project from its title and text alone.
 - `knowledge`-type memos are commodity. Do not build principles from them; the material is `decision` / `operation` and design-doc decisions.
 - Do not duplicate existing material. Skip anything that semantically matches an existing `principle` memo (find_similar ~0.85+) or an existing pending candidate.

package/dist/cli/skills/paput-public-profile-summary/SKILL.md

@@ -16,9 +16,9 @@ Generate the public profile shown on the AI Summary tab. The lead of the page is
    - If the index is empty, base the summary on the skill sheet, `knowledge_map`, and `growing_areas` alone, set `stances` to an empty array, and note that judgment/operation/principle material is thin.
 3. Synthesize `stances` (the lead of the page):
    - Cluster the fetched `decision` / `operation` memos by theme. Turn each cluster into one `stance` whose `statement` is a SINGLE posture-level line, not an implementation note.
-   - Vocabulary altitude (MOST IMPORTANT): write the line in plain, non-expert vocabulary a non-technical recruiter grasps in one read. Banning identifiers is NOT enough — also keep domain jargon and English technical terms OUT of the line (e.g. idempotent / 冪等, check-then-act, soft signal, labeler, mock, fail-closed, TOCTOU, IDOR). Those live only in the drill-down evidence memos. Aim for ~40-70 Japanese chars, one clause.
-   - Keep the rejected alternative: state the posture plus what it chooses over what it rejects ("B, not A"). This contrast is the non-copyable, falsifiable core — when you plain-language the wording, drop the jargon but NEVER the contrast. Example — good: `セキュリティの重大さは警告の数ではなく「実際に悪用が届くか」で見極め、表面的な対症対応は採らない`. Avoid (jargon / too dense): `セキュリティは fail-closed と多層防御を既定にし、url ではなく http_url で javascript: を弾き、レート制限は TOCTOU を原子化…`.
-   - Lead with **3-4 stances total (NOT 6)**, with one clear anchor (筆頭) — the single most differentiating — and the rest ordered by strength. MERGE overlapping clusters aggressively (e.g. security-reachability + concurrency-correctness → one "design for how it breaks" stance). Demote the rest to drill-down evidence; do not emit them at the top.
+   - Vocabulary altitude (MOST IMPORTANT): write the line in plain, non-expert vocabulary a non-technical recruiter grasps in one read. Banning identifiers is NOT enough — also keep domain jargon and English technical terms OUT of the line (e.g. idempotent, check-then-act, soft signal, labeler, mock, fail-closed, TOCTOU, IDOR). Those live only in the drill-down evidence memos. Aim for ~40-70 Japanese chars, one clause.
+   - Keep the rejected alternative: state the posture plus what it chooses over what it rejects ("B, not A"). This contrast is the non-copyable, falsifiable core — when you plain-language the wording, drop the jargon but NEVER the contrast. Example — good: `Judge how serious a security issue is by whether an exploit can actually reach it, not by the warning count; surface-level symptomatic fixes are not taken.` Avoid (jargon / too dense): `Defaults to fail-closed and defense-in-depth, blocks javascript: via http_url instead of url, and atomizes rate limiting against TOCTOU…`.
+   - Lead with **3-4 stances total (NOT 6)**, with one clear anchor — the single most differentiating — and the rest ordered by strength. MERGE overlapping clusters aggressively (e.g. security-reachability + concurrency-correctness → one "design for how it breaks" stance). Demote the rest to drill-down evidence; do not emit them at the top.
    - Exclude from the lead any stance that reads as PaPut's / this product's own philosophy, or is self-referential or self-congratulatory rather than a portable professional posture (e.g. "sort knowledge by AI-resistance"). If kept, reword it to hold on any project and keep it out of the lead.
    - Stances are the JUDGMENT/PRACTICE axis. Keep them distinct from `strength_labels` (the skill/what-they-can-do axis). Do not restate a strength as a stance, and avoid leaning a stance and a strength on the same memos — give each its own best evidence.
    - Dissolve `principle` into the wording of the stances; do not emit a separate principle section.
@@ -32,7 +32,7 @@ Generate the public profile shown on the AI Summary tab. The lead of the page is
 
 ## Output
 
-- stances (the lead): 3-4 stances total with one clear anchor (筆頭), ordered by strength. Each has `type`, a single-clause `statement` (~40-70 Japanese chars) in plain non-expert vocabulary stating the posture and what it chooses over what it rejects — principle dissolved into the wording, domain jargon / English technical terms left to the drill-down — and `supporting_memo_ids` (public memo IDs backing it). This is the main material the AI Summary tab leads with.
+- stances (the lead): 3-4 stances total with one clear anchor, ordered by strength. Each has `type`, a single-clause `statement` (~40-70 Japanese chars) in plain non-expert vocabulary stating the posture and what it chooses over what it rejects — principle dissolved into the wording, domain jargon / English technical terms left to the drill-down — and `supporting_memo_ids` (public memo IDs backing it). This is the main material the AI Summary tab leads with.
 - headline: concise one-line catchphrase for the AI Summary hero, demoted to a thin intro. In Japanese, aim for 45-65 chars and keep it under 80 chars. In other languages, keep it similarly compact.
 - profile_summary: a thin 2-3 sentence intro layer for a recruiter. Convey the role and overall posture in prose; do not enumerate techniques here — the stances carry the detail. Keep it lighter than the stances, not denser.
 - strength_labels: top 3-5 strengths. Each has a label, an optional short description, evidence via `category_names` and `project_ids`, and `supporting_memo_ids` (public memo IDs backing the strength) where available.
@@ -56,13 +56,13 @@ Use only public materials:
 - Drop any claim you cannot back with public material. Every stance must have at least one public memo ID in `supporting_memo_ids`; if a stance or strength has no public-memo backing, do not emit it.
 - `knowledge`-type memos are commodity. Do not build stances from them; stances come from `decision` / `operation` (with `principle` dissolved in).
 - Use only public memo IDs from the `public_summary_memos` index for `supporting_memo_ids`. The server drops any ID that is not the user's own public memo, so do not pad with guesses.
-- Keep each `statement` to one clause in plain, non-expert vocabulary (the posture and what it chooses over what it rejects). Banning identifiers is not enough — keep domain jargon and English technical terms (idempotent / 冪等, check-then-act, soft signal, mock, fail-closed, TOCTOU, IDOR, etc.) out of the line; they belong in the drill-down evidence memos. A non-technical recruiter must grasp the line in one read, while the rejected-alternative contrast stays in the line.
-- Lead with 3-4 stances total with one clear anchor (筆頭), not 6. Merge overlapping clusters aggressively instead of emitting near-duplicate lines, and demote weaker stances to the drill-down evidence. Fewer, sharper stances beat many dense ones.
+- Keep each `statement` to one clause in plain, non-expert vocabulary (the posture and what it chooses over what it rejects). Banning identifiers is not enough — keep domain jargon and English technical terms (idempotent, check-then-act, soft signal, mock, fail-closed, TOCTOU, IDOR, etc.) out of the line; they belong in the drill-down evidence memos. A non-technical recruiter must grasp the line in one read, while the rejected-alternative contrast stays in the line.
+- Lead with 3-4 stances total with one clear anchor, not 6. Merge overlapping clusters aggressively instead of emitting near-duplicate lines, and demote weaker stances to the drill-down evidence. Fewer, sharper stances beat many dense ones.
 - Keep stances that read as PaPut's / this product's own philosophy or are self-referential out of the lead. A lead stance must be a portable professional posture that holds on any project, not a description of this service's thesis.
 - Keep `stances` (judgment/practice) and `strength_labels` (skill axis) distinct: do not restate the same theme in both, and avoid backing a stance and a strength with the same memos. If a theme appears in both, keep it as a stance and let the strength cover a different angle.
 - Keep `profile_summary` lighter than the stances. It is a thin intro, not a second, denser pass of the same detail.
 - Keep `headline` focused on the role and core value proposition. Do not pack every major technology, domain, lifecycle phase, and AI/MCP detail into it.
-- Prefer a readable headline such as `Go・TypeScript・AWSを軸に、AI/MCPまで設計・実装するフルスタックエンジニア` over a long comma-separated inventory.
+- Prefer a readable headline such as `Full-stack engineer who, centered on Go, TypeScript, and AWS, designs and implements through to AI/MCP` over a long comma-separated inventory.
 - Move supporting details from an overlong `headline` into `profile_summary`, `strength_labels`, and `project_highlights`.
 - Generate the `headline`, `profile_summary`, and `strength_labels` first, then select `project_highlights` as evidence that supports that headline and those strengths.
 - If project material exists, always include `project_highlights` in the draft. Do not ask the user whether to add them.

package/package.json

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