paput-mcp 4.2.7 → 4.2.9
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -53,9 +53,24 @@ Guidance:
|
|
|
53
53
|
|
|
54
54
|
- Capture candidates are reusable decision criteria, procedures, or principles, so prefer `decision` / `operation` / `principle` when they fit; use `knowledge` for commodity technical know-how.
|
|
55
55
|
- `decision` / `operation` / `principle` are the primary material for the public AI summary; `knowledge` usually is not.
|
|
56
|
+
- Tagging review — do not under-label. The default failure mode is dropping a judgment memo into `knowledge` and missing `decision` / `operation` / `principle`; this is a main reason the `principle` axis stays thin. Consider the durable three FIRST and use `knowledge` only when none genuinely fit. Quick catches: a stated reason for choosing or avoiding an option → `decision`; an operating practice (how you measure, review, run, or verify) → `operation`; a generalized stance one level above a single decision → `principle`. Before finalizing `memo_type_keys`, re-read the candidate once and ask "is there a judgment here that I labeled as mere knowledge?". Do not over-correct either: `principle` needs an explicitly generalized stance, not a one-off opinion — keep it honest against the Quality Bar.
|
|
56
57
|
- 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.
|
|
57
58
|
- 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.
|
|
58
59
|
|
|
60
|
+
## Eliciting scarce operating practices (eval / observability)
|
|
61
|
+
|
|
62
|
+
`operation` is a primary public-summary axis, but its eval / observability / measurement part is the scarcest and most easily lost — it surfaces as "how the work was measured and watched", not as a deliverable, so generic free-form capture tends to miss it or leave thin, ad-hoc candidates. When the conversation touched measurement, evaluation, monitoring, alerting, test strategy, SLO / SLI, threshold or pass-fail tuning, or incident review, do not let it pass as a work log: actively draw out the reusable practice and capture it as `operation` (or `principle` for a stated stance, `decision` for an adopt/reject criterion).
|
|
63
|
+
|
|
64
|
+
Draw out only what fits the conversation — do not interrogate:
|
|
65
|
+
|
|
66
|
+
- What was measured, and why that signal rather than another?
|
|
67
|
+
- How was signal separated from noise?
|
|
68
|
+
- How was the threshold / pass-fail decided — by feel, or by offline evaluation?
|
|
69
|
+
- What is watched in production, and where were alerts placed, and why there?
|
|
70
|
+
- What did a failure or false positive teach, and how did it change the judgment?
|
|
71
|
+
|
|
72
|
+
Generalize one level above the project: drop service, metric, and dashboard names; keep the criterion, the rationale, and the verification method. A candidate here must carry at least one of measurement target + why, threshold rationale, or verification method — a bare "added monitoring" or "wrote tests" is a work log, not knowledge. This is a lens for capturing the user's methodology, not a feature: do not turn PaPut into an eval or monitoring tool.
|
|
73
|
+
|
|
59
74
|
## Quality Bar
|
|
60
75
|
|
|
61
76
|
Before adding a candidate, make sure the body preserves enough reasoning for future reuse. A good candidate is not just a conclusion; it should include the relevant problem context, decision criteria, applicability conditions, tradeoffs, pitfalls, operational guidance, or verification method.
|
|
@@ -94,6 +94,26 @@ project, for someone else to learn? If yes, capture it as `operation` or
|
|
|
94
94
|
`principle`, generalized one level above the specific session. If it is only
|
|
95
95
|
about this tool's mechanics or this one session's events, exclude it.
|
|
96
96
|
|
|
97
|
+
### Capture the eval / observability axis
|
|
98
|
+
|
|
99
|
+
Eval, observability, and measurement practices are another scarce, durable
|
|
100
|
+
`operation` sub-axis that is easy to lose — they show up as how the work was
|
|
101
|
+
measured and watched, not as the work itself. When a session touched
|
|
102
|
+
measurement, evaluation, monitoring, alerting, test strategy, SLO / SLI,
|
|
103
|
+
threshold or pass-fail tuning, or incident review, capture the reusable practice
|
|
104
|
+
as `operation` (or `principle` for a stance, `decision` for an adopt/reject
|
|
105
|
+
criterion). Look for:
|
|
106
|
+
|
|
107
|
+
- What was measured and why that signal; how signal was separated from noise.
|
|
108
|
+
- How a threshold or pass-fail was decided — by feel or by offline evaluation.
|
|
109
|
+
- What is watched in production and where alerts sit, and why there.
|
|
110
|
+
- What a failure or false positive changed in the judgment.
|
|
111
|
+
|
|
112
|
+
Generalize above the project (drop service / metric / dashboard names, keep the
|
|
113
|
+
criterion and verification). A bare "added monitoring" or "wrote tests" with no
|
|
114
|
+
rationale or verification is a work log — exclude it. This is a lens for
|
|
115
|
+
capturing methodology, not a reason to log routine test/monitoring chores.
|
|
116
|
+
|
|
97
117
|
### Do not add these to pending
|
|
98
118
|
|
|
99
119
|
- Project-specific specifications, screen names, button names, business workflows, operational rules, or local context.
|
|
@@ -119,6 +139,17 @@ Classify each candidate with one or more memo types via `memo_type_keys`:
|
|
|
119
139
|
AI summary and the principle synthesizer; `knowledge` usually is not. Prefer the
|
|
120
140
|
durable types when they fit, and do not force a type when none does.
|
|
121
141
|
|
|
142
|
+
Tagging review — do not under-label. The default failure mode is dropping a
|
|
143
|
+
judgment memo into `knowledge` and missing `decision` / `operation` /
|
|
144
|
+
`principle`; this is a main reason the `principle` axis stays thin. Consider the
|
|
145
|
+
durable three FIRST and use `knowledge` only when none genuinely fit. Quick
|
|
146
|
+
catches: a stated reason for choosing or avoiding an option → `decision`; an
|
|
147
|
+
operating practice (how you measure, review, run, or verify) → `operation`; a
|
|
148
|
+
generalized stance one level above a single decision → `principle`. Before
|
|
149
|
+
finalizing `memo_type_keys`, re-read the candidate once and ask whether there is
|
|
150
|
+
a judgment you labeled as mere knowledge. Do not over-correct: `principle` needs
|
|
151
|
+
an explicitly generalized stance, not a one-off opinion.
|
|
152
|
+
|
|
122
153
|
## Notes
|
|
123
154
|
|
|
124
155
|
- Do not save directly to PaPut.
|