[LilMGenius]

Summary

Under target policy, bsk cooperate sync --json returns two observation ids that differ:

{
  "context_id": "4d8a3ca5-…",
  "control_policy": "target",
  "observation": { "observation_id": "6c181ea9-…", "ref_count": 1, "text": "@vom 1 …" },
  "observation_id": "6b8da7fc-…"
}

Scripts, untargeted keys, visual clicks and displacement-only drags need the top-level one. An agent that passes the nested observation.observation_id gets this back, with nothing that tells it which id to use:

$ bsk wheel --delta-y 100 --session hatq --tab-id 527377117 --context 4d8a3ca5-… --observation 6c181ea9-…
error: this action needs an explicit current observation
hint: Synchronize, inspect the result and pass its observation_id explicitly with --observation (plugin: observationId).

If the agent follows that hint and syncs again, it gets a new pair of ids and can pick the wrong one again. The same command with the top-level 6b8da7fc-… succeeds. Both runs used CLI, daemon and extension 0.4.1 (protocol 1.8), on Chrome 156 on Windows 11, in a session-owned tab on example.com.

Cause

apps/extension/src/cooperation/controller.ts: sync returns observation_id: context.observationId at the top level (line 753), and the nested observation is the snapshot reply, whose observation_id is the ref store's token (RefStore.observationId). The strict check at line 1440 compares only against context.observationId. The sync guidance (line 795), the observation_required recovery (line 1446), the CLI fallback hint in crates/bsk-cli/src/cli/render_error.rs and both skill/references/cooperation.md copies all say "this sync's observation_id" without saying which of the two fields that means.

Change

• The recovery and the target-policy sync guidance now name the reply's top-level observation_id and say the nested observation.observation_id is a different id.
• The CLI fallback hint for observation_required / observation_changed says "top-level observation_id".
• Both skill references add one sentence saying that the nested observation.observation_id names the rendered ref map and is not the receipt.
• An [Unreleased] changelog entry.

Behavior is unchanged: the same ids are accepted and refused, and the error code and reason stay the same.

Verification

New test in target-policy.test.ts: it passes the ref-map token to tool.evaluate and expects observation_required, effect_state: "none", no CDP call, and a recovery that names the top-level observation_id. The top-level id then succeeds.

Run	Result
New test at b8f2d4f (main), fix reverted	fails: recovery is the old "pass its observation_id" text
Same test with this change	passes
target-policy.test.ts + controller.test.ts	283 passed
pnpm --filter @browser-skill/extension test	195 files passed, 40 skipped; 3522 tests passed, 358 skipped
pnpm --filter @browser-skill/extension compile (tsc)	clean
biome check on the changed TS files	clean
node scripts/check-skill-bundles.mjs, node scripts/check-crate-skill.mjs	valid
cargo fmt --all -- --check	clean
cargo test -p bsk --lib render_error	25 passed

Limits

• Messages only. A larger fix would make the two fields share a name, or drop the nested id from the sync reply. This PR does neither, because the eval cases and the DSH plugin read both fields.
• cargo clippy -p bsk --lib -D warnings on Windows reports three errors in daemon/file_transfer.rs and skill_install/harness.rs. This PR does not touch either file. The Linux CI job is the gate for that check.