* perf(session): send one projection frame per committed event
* fix(session): deliver keys changed before a drive failure; address review
* perf(session): carry projection frame changes as key and val entries
A new Agent Note owns the shipped defaults and the original apply_patch note
keeps its opt-in decision with a supersession link; the policy README, the
tool-catalog note, the filesystem page, and the fs group README state the
current defaults without evaluation figures. The PTC overlay sets
`applyPatch: false` so the SDK and Desktop PTC tool sets match without a
parity exception; the fixed-budget compaction scenarios pin the tool set in
their live patches too; the apply-patch composition drops its no-op override.
The upgrade guide scopes the change to base-backed profiles, the README
refusal example is one every composition can produce, the integration suite
names its deployments by guard, and the keyless SDK smoke edits a file the
model never read through the shipped profile.
Takes master's re-recorded plan-review, creation-recommendations, and
plugin-recommendations scenarios from the base and refreshes their headers
and schema sidecar for the enabled apply_patch tool.
Evaluation on the shipped compositions decided the defaults: the `dsh-base`
`tool-fs` row and the Web `standard` preset enable apply_patch, keeping the
SDK and Desktop `standard` tool sets equal (the SDK PTC overlay keeps the
base row while the Desktop PTC preset lists its own, which the parity
exceptions record); the `fs-observation-policy` row ships `disabled: true`,
so write, edit, and apply_patch mutate unconditionally in every profile, and
the package is classified as an optional product package.
The write and edit guidance stops citing the policy as the default and the
apply_patch guidance asks for enough hunk context instead of a prior read.
The two recordings that capture a policy refusal re-enable the row through a
per-scenario runtime.cordis.yml; the fixed-budget compaction scenarios pin
`applyPatch: false` so their recorded thresholds hold; every other sidecar
and recorded header follows. An upgrade guide records the default change.
This pull request lands the tool; switching the shipped defaults is a
separate pull request stacked on it. Every shipped `tool-fs` row states
`applyPatch: false`, the `fs-observation-policy` row stays mounted, the
write, edit, and apply_patch guidance names the policy, and every recorded
expectation outside the apply-patch scenarios returns to the master
baseline. The upgrade guide, the parity exception, and the optional
classification of the policy package move to the stacked change.
Keeps the apply_patch toolview registration with master's file-menu inject,
takes master's shortened slot JSDoc, re-adds the seven filesystem type-equiv
manifest entries, regenerates the event matrix and client catalogs, moves the
fs-observation-policy upgrade guide under v0.2.2-alpha.2 with the matching
fs-patch version, and refreshes the two SDK scenarios master added for the
write and edit guidance change.
Evaluation on the shipped Web composition decided the defaults: the
`fs-observation-policy` row in dsh-base ships `disabled: true`, so write,
edit, and apply_patch mutate unconditionally in every profile; the Web
`standard` preset lists apply_patch; and the tool-fs `applyPatchGuard` switch
is gone, apply_patch always consulting the fs/* intent waterfalls like the
other mutating tools.
The write and edit guidance stops citing the policy as the default, and the
apply_patch guidance asks for enough hunk context instead of a prior read.
The two recordings that capture a policy refusal (fs-policy-reject and
apply-patch-rejected) re-enable the row through a per-scenario
runtime.cordis.yml; every other sidecar follows the prompt change, and the
Web standard-preset recordings gain the apply_patch schema. An upgrade guide
records the default change.
Magolor