paput-mcp 4.1.0 → 4.2.0

package/dist/cli/skills/paput-principle-synthesizer/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: paput-principle-synthesizer
+description: Use this to synthesize cross-cutting principle candidates from the user's accumulated public decision/operation memos (and private design docs) and add them to pending. It surfaces the stances that run through many decisions — the thinnest, most AI-durable memo type — which the per-conversation paput-capture cannot reach. It only proposes to pending; it never saves to PaPut.
+---
+
+# PaPut Principle Synthesizer
+
+Synthesize `principle` candidates by reading the user's accumulated `decision` / `operation` memos (and, as substrate, their private `design_doc` project documents) as a whole, finding the stances that run through many of them, and proposing each as a `principle` pending candidate.
+
+A `principle` is a stance explicitly generalized one level above individual decisions — what the person optimizes for and what they reject across cases. It rarely falls out of a single conversation, so `paput-capture` (which works per session) structurally under-produces it. This skill fills that gap by working across the whole accumulated corpus. It is the persistence counterpart of the public-profile ◆ stances: it turns the cross-cutting synthesis into reusable `principle` material.
+
+Use this when the user wants to thicken their `principle` memos, distill recurring decisions into stated principles, or refresh principle candidates from accumulated knowledge.
+
+## Workflow
+
+1. Gather the material:
+   - Call `paput_get_public_profile_context`. Use `public_summary_memos` — the complete index (id, title, memo_types, updated_at; no bodies) of ALL the user's PUBLIC `decision` / `operation` / `principle` memos. The `decision` / `operation` entries are the synthesis material; the existing `principle` entries are the de-dup baseline.
+   - As substrate, call `paput_get_project_context` and read the `design_doc` documents in the index with `paput_get_project_document(id)`. Design docs hold decisions with reasons and rejected alternatives — strong principle material — but they are private and project-specific.
+2. Read the bodies of the memos you plan to cluster with `paput_get_memo` (index first, fetch on demand — do not bulk-fetch everything).
+3. Cluster across documents by theme. Look for a stance that runs through SEVERAL decisions/operations (and design-doc decisions), not a single memo restated.
+4. Synthesize each qualifying cluster into one `principle` candidate:
+   - 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).
+   - 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. De-dup before adding:
+   - For each candidate, call `paput_find_similar_memos` (it searches all of the user's memos, public and private). Treat a top score of ~0.85 or higher against an existing memo as a near-duplicate and skip it.
+   - Also compare against the existing `principle` entries in `public_summary_memos`, and check `paput_list_pending_candidates` so you do not duplicate a pending candidate.
+6. Add only the non-duplicate, generalized, project-independent candidates with `paput_add_knowledge_candidates` (memo_type_keys=['principle']). Add to pending only.
+7. Report each added candidate: title, categories, memo type, candidate id, and the source memos it was synthesized from.
+8. Do NOT save to PaPut. Saving a pending candidate is handled by `paput-save`, only when the user explicitly approves it.
+
+## Quality Bar
+
+- A `principle` must run through at least two or three decisions/operations. A single decision reworded is NOT a principle — drop it (or leave it as the decision memo it already is).
+- 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. Skip anything that semantically matches an existing `principle` memo (find_similar ~0.85+) or an existing pending candidate.
+- Do not leak private design-doc specifics into a candidate. Default `is_public: false`; the user decides visibility at review time.
+- The save API sits behind a WAF that inspects the body. Write command, SQL, and markup examples as prose or pseudo-notation, not raw executable strings.
+
+## Notes
+
+- This skill only proposes to pending. It never writes memos directly; final saves go through `paput-save` with explicit user approval.
+- It complements `paput-capture` (per-conversation, generalizable knowledge) by working across the accumulated corpus to reach the cross-cutting `principle` axis.
+- If the index has too few `decision` / `operation` memos to find a cross-cutting stance, say so and add nothing rather than forcing weak principles.

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

@@ -15,10 +15,12 @@ Generate the public profile shown on the AI Summary tab. The lead of the page is
    - There is no fixed limit; the index is the full set. Fetch as many bodies as you need for a grounded summary.
    - 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 recruiter-altitude line that weaves in what the person chose and what they rejected (e.g. "moved を選び destroy/create を却下", "fail-closed を既定にしサイレントフォールバックを却下").
-   - Set `type` to `decision` or `operation` per the cluster. Aim for about 3 decision and 3 operation stances; adjust to the real density.
+   - Cluster the fetched `decision` / `operation` memos by theme. Turn each cluster into one `stance` whose `statement` is a SINGLE recruiter-altitude line at the level of a posture, not an implementation note.
+   - Write the `statement` as ONE clause: the posture plus what it chooses over what it rejects. Aim for roughly 40-70 Japanese chars. Do NOT pack two or three concrete techniques into the line. Example — good: `セキュリティは fail-closed と多層防御を既定にし、表層的な対症対応は却下する`. Too low / too dense (avoid): `url ではなく http_url で javascript: を弾き、削除も所有者条件をクエリに残し、レート制限は TOCTOU を原子化…`. The concrete techniques belong in the drill-down evidence memos, NOT in the statement.
+   - Keep about **3 decision and 3 operation stances (6 total, hard cap ~8)**. If clusters overlap, MERGE them into one stance rather than emitting near-duplicate lines. Pick the strongest, most distinctive postures.
+   - 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.
-   - For each stance, set `supporting_memo_ids` to the public memo IDs from the index that back it (these become the drill-down judgment cards). Drop any stance you cannot back with at least one public memo ID.
+   - For each stance, set `supporting_memo_ids` to the public memo IDs from the index that back it (these become the drill-down judgment cards, where the concrete techniques live). Drop any stance you cannot back with at least one public memo ID.
 4. Generate the supporting layers (`headline`, `profile_summary`, `strength_labels`, `project_highlights`) from the context plus the fetched memo bodies. For each `strength_label`, set `supporting_memo_ids` to the public memo IDs that back it where available.
 5. Present the draft in the user's language and tone. Lead with the `stances`, then the supporting layers. Explain what each field will become.
 6. Do not save unless the user explicitly asks to save it.
@@ -27,9 +29,9 @@ Generate the public profile shown on the AI Summary tab. The lead of the page is
 
 ## Output
 
-- stances (the lead): about 3 `decision` and 3 `operation` stances. Each has `type`, a one-line `statement` that weaves in the chosen and rejected options (principle dissolved into the wording), and `supporting_memo_ids` (public memo IDs backing it). This is the main material the AI Summary tab leads with.
+- stances (the lead): about 3 `decision` and 3 `operation` stances (6 total, hard cap ~8). Each has `type`, a single-clause `statement` (~40-70 Japanese chars) stating the posture and what it chooses over what it rejects — principle dissolved into the wording, concrete techniques 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: 3-4 sentence overall summary written for a recruiter, also a thin intro layer. Convey strengths and continuity in prose.
+- 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.
 - project_highlights: required when the context contains at least one project with enough material. Include up to 2-3 representative public-profile project highlights. Each has `project_id`, `title`, `summary` (120-200 Japanese chars or similarly concise in the user's language), optional `strength_labels`, and up to 3 `achievement_bullets`.
 
@@ -51,6 +53,10 @@ 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 at recruiter altitude (the posture and what it chooses over what it rejects). Never pack two or three concrete techniques or specific identifiers into a statement — those belong in the drill-down evidence memos. A recruiter must grasp the line in one read.
+- Cap stances at about 6 (hard cap ~8). Merge overlapping clusters instead of emitting near-duplicate lines. Fewer, sharper stances beat many dense ones.
+- 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.
 - Move supporting details from an overlong `headline` into `profile_summary`, `strength_labels`, and `project_highlights`.

package/dist/handlers/get-public-profile-context/handler.js

@@ -65,13 +65,15 @@ structuredContent.public_summary_memos is an index of ALL the person's PUBLIC de
 - If the index is empty, say so and base the summary on the skill sheet, knowledge_map, and growing_areas alone, noting that judgment/operation/principle material is thin.
 
 Produce these fields. stances is the lead of the page; the rest are supporting layers.
-1. stances (the lead): cluster the fetched decision/operation memos by theme and turn each cluster into one stance. Each stance has type (decision | operation), a one-line statement that weaves in what was chosen and what was rejected (dissolve principle into the wording), and supporting_memo_ids (the public memo IDs from the index that back it; these become the drill-down judgment cards). Aim for about 3 decision and 3 operation stances. Drop any stance you cannot back with at least one public memo ID.
+1. stances (the lead): cluster the fetched decision/operation memos by theme and turn each cluster into one stance. Each stance has type (decision | operation), a single-clause statement at recruiter altitude (~40-70 Japanese chars) stating the posture and what it chooses over what it rejects (dissolve principle into the wording), and supporting_memo_ids (the public memo IDs from the index that back it; these become the drill-down judgment cards). Keep about 3 decision and 3 operation stances (6 total, hard cap ~8); merge overlapping clusters instead of emitting near-duplicate lines. Do NOT pack two or three concrete techniques or specific identifiers into a statement — those live in the drill-down memos. Drop any stance you cannot back with at least one public memo ID.
 2. headline: a one-line catchphrase of what the person can do (around 100 characters), demoted to a thin intro.
-3. profile_summary: a 3-4 sentence overall summary written for a recruiter, also a thin intro. Ground it in the judgment, operating practices, and principles visible in the fetched decision/operation/principle memo bodies, not just a list of technologies.
-4. strength_labels: the 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.
+3. profile_summary: a thin 2-3 sentence intro for a recruiter. Convey the role and overall posture; do not enumerate techniques here (the stances carry the detail). Keep it lighter than the stances, not denser.
+4. strength_labels: the top 3-5 strengths (the skill axis, kept distinct from stances). 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.
 
 Guidance:
 - Tie strengths and stances to concrete projects and the fetched public memos. Do not exaggerate.
+- Keep each statement to one clause at recruiter altitude; a recruiter must grasp it in one read. Concrete techniques and identifiers belong in the drill-down evidence, not the statement.
+- Keep stances (judgment/practice) distinct from strength_labels (skill axis): do not restate the same theme in both, and avoid backing a stance and a strength with the same memos.
 - Drop any claim you cannot back with public material. Build stances only from decision/operation memos (principle dissolved in); knowledge-type memos are commodity and are not stance material.
 - Use only public memo IDs from the 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.
 - Do not present memo counts as skill proficiency. Activity volume is not mastery.

package/dist/handlers/get-public-profile-context/handler.js.map

@@ -1 +1 @@
-{"version":3,"file":"handler.js","sourceRoot":"","sources":["../../../src/handlers/get-public-profile-context/handler.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,uBAAuB,EAAE,MAAM,mCAAmC,CAAC;AAE5E,MAAM,CAAC,KAAK,UAAU,6BAA6B,CACjD,KAA0C,EAC1C,SAAoB;IAEpB,IAAI,CAAC;QACH,MAAM,OAAO,GAAG,MAAM,uBAAuB,CAAC,SAAS,CAAC,CAAC;QACzD,MAAM,UAAU,GAAG,OAAO,CAAC,WAAW,CAAC;QACvC,MAAM,iBAAiB,GAAG,UAAU,EAAE,mBAAmB,IAAI,CAAC,CAAC;QAC/D,MAAM,YAAY,GAAG,UAAU,EAAE,QAAQ,EAAE,MAAM,IAAI,CAAC,CAAC;QACvD,MAAM,aAAa,GAAG,UAAU,EAAE,eAAe,EAAE,MAAM,IAAI,CAAC,CAAC;QAC/D,MAAM,YAAY,GAAG,KAAK,CAAC,OAAO,CAAC,OAAO,CAAC,aAAa,CAAC;YACvD,CAAC,CAAC,OAAO,CAAC,aAAa,CAAC,MAAM;YAC9B,CAAC,CAAC,CAAC,CAAC;QACN,MAAM,gBAAgB,GAAG,KAAK,CAAC,OAAO,CAAC,OAAO,CAAC,oBAAoB,CAAC;YAClE,CAAC,CAAC,OAAO,CAAC,oBAAoB,CAAC,MAAM;YACrC,CAAC,CAAC,CAAC,CAAC;QAEN,MAAM,MAAM,GAAG,WAAW,CAAC;YACzB,iBAAiB;YACjB,YAAY;YACZ,aAAa;YACb,YAAY;YACZ,gBAAgB;YAChB,iBAAiB,EAAE,OAAO,CAAC,UAAU,EAAE,eAAe,CAAC;SACxD,CAAC,CAAC;QAEH,OAAO;YACL,iBAAiB,EAAE;gBACjB,GAAG,OAAO;gBACV,MAAM;aACP;YACD,OAAO,EAAE;gBACP;oBACE,IAAI,EAAE,MAAM;oBACZ,IAAI,EAAE;uBACO,iBAAiB;YAC5B,YAAY;4BACI,aAAa;iBACxB,YAAY;gCACG,gBAAgB;4BACpB,UAAU,EAAE,eAAe,CAAC,CAAC,CAAC,WAAW,CAAC,CAAC,CAAC,eAAe;;EAErF,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,gDAAgD,YAAY,EAAE;iBACrE;aACF;YACD,OAAO,EAAE,IAAI;SACd,CAAC;IACJ,CAAC;AACH,CAAC;AAED,SAAS,WAAW,CAAC,OAOpB;IACC,OAAO;;;;;;;;;;;;;;;;;;;;;;;;yBAwBgB,OAAO,CAAC,iBAAiB;cACpC,OAAO,CAAC,YAAY;8BACJ,OAAO,CAAC,aAAa;mBAChC,OAAO,CAAC,YAAY;mCACJ,OAAO,CAAC,gBAAgB;8BAC7B,OAAO,CAAC,iBAAiB,CAAC,CAAC,CAAC,WAAW,CAAC,CAAC,CAAC,eAAe;;mPAE4J,CAAC;AACpP,CAAC"}
+{"version":3,"file":"handler.js","sourceRoot":"","sources":["../../../src/handlers/get-public-profile-context/handler.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,uBAAuB,EAAE,MAAM,mCAAmC,CAAC;AAE5E,MAAM,CAAC,KAAK,UAAU,6BAA6B,CACjD,KAA0C,EAC1C,SAAoB;IAEpB,IAAI,CAAC;QACH,MAAM,OAAO,GAAG,MAAM,uBAAuB,CAAC,SAAS,CAAC,CAAC;QACzD,MAAM,UAAU,GAAG,OAAO,CAAC,WAAW,CAAC;QACvC,MAAM,iBAAiB,GAAG,UAAU,EAAE,mBAAmB,IAAI,CAAC,CAAC;QAC/D,MAAM,YAAY,GAAG,UAAU,EAAE,QAAQ,EAAE,MAAM,IAAI,CAAC,CAAC;QACvD,MAAM,aAAa,GAAG,UAAU,EAAE,eAAe,EAAE,MAAM,IAAI,CAAC,CAAC;QAC/D,MAAM,YAAY,GAAG,KAAK,CAAC,OAAO,CAAC,OAAO,CAAC,aAAa,CAAC;YACvD,CAAC,CAAC,OAAO,CAAC,aAAa,CAAC,MAAM;YAC9B,CAAC,CAAC,CAAC,CAAC;QACN,MAAM,gBAAgB,GAAG,KAAK,CAAC,OAAO,CAAC,OAAO,CAAC,oBAAoB,CAAC;YAClE,CAAC,CAAC,OAAO,CAAC,oBAAoB,CAAC,MAAM;YACrC,CAAC,CAAC,CAAC,CAAC;QAEN,MAAM,MAAM,GAAG,WAAW,CAAC;YACzB,iBAAiB;YACjB,YAAY;YACZ,aAAa;YACb,YAAY;YACZ,gBAAgB;YAChB,iBAAiB,EAAE,OAAO,CAAC,UAAU,EAAE,eAAe,CAAC;SACxD,CAAC,CAAC;QAEH,OAAO;YACL,iBAAiB,EAAE;gBACjB,GAAG,OAAO;gBACV,MAAM;aACP;YACD,OAAO,EAAE;gBACP;oBACE,IAAI,EAAE,MAAM;oBACZ,IAAI,EAAE;uBACO,iBAAiB;YAC5B,YAAY;4BACI,aAAa;iBACxB,YAAY;gCACG,gBAAgB;4BACpB,UAAU,EAAE,eAAe,CAAC,CAAC,CAAC,WAAW,CAAC,CAAC,CAAC,eAAe;;EAErF,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,gDAAgD,YAAY,EAAE;iBACrE;aACF;YACD,OAAO,EAAE,IAAI;SACd,CAAC;IACJ,CAAC;AACH,CAAC;AAED,SAAS,WAAW,CAAC,OAOpB;IACC,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;yBA0BgB,OAAO,CAAC,iBAAiB;cACpC,OAAO,CAAC,YAAY;8BACJ,OAAO,CAAC,aAAa;mBAChC,OAAO,CAAC,YAAY;mCACJ,OAAO,CAAC,gBAAgB;8BAC7B,OAAO,CAAC,iBAAiB,CAAC,CAAC,CAAC,WAAW,CAAC,CAAC,CAAC,eAAe;;mPAE4J,CAAC;AACpP,CAAC"}

package/package.json

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