blob: 6fc6c8202de0dd9c756a347e33bab78ee092f20f (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
# Checklist
Use this checklist when reviewing a `libmcp` consumer.
- Does a stable host own the public session?
- Is the public session backed by the shared host-session kernel rather than
ad hoc initialize/reexec glue?
- Is worker fragility isolated behind an explicit replay policy?
- Are replay contracts typed and local to the request surface?
- Are faults typed and connected to recovery semantics?
- Do tool surfaces cross an explicit projection boundary rather than serializing
raw domain/store structs directly?
- Do nontrivial tools default to porcelain output?
- Are `render` and `detail` treated as orthogonal controls?
- Does `detail=concise` return an actual summary rather than the full payload?
- Are the projection traits or derive-macro happy path used on hot surfaces,
with generic JSON fallbacks reserved for explicit escape hatches?
- Are library render helpers used where bespoke porcelain has not yet been
justified?
- Is structured JSON still available where exact consumers need it?
- Are inputs normalized where the semantics are still unambiguous?
- Are health and telemetry available?
- Is event telemetry append-only and useful for postmortem analysis?
- Does the recovery test matrix cover the failure modes actually observed?
- Is the installed `$mcp-bootstrap` skill sourced from this repository?
|