Best possible solution:

Use #81312 as the canonical fix path, address its deduplication review feedback, and let the merged PR close the linked openclaw-lark bug.

Do we have a high-confidence way to reproduce the issue?

Yes. Source inspection shows current main creates bundled capability records without contracts and then validates captured tools against record.contracts; I did not run a live openclaw-lark scenario in this read-only review.

Is this the best way to solve the issue?

No for merging this PR now. The code direction is narrow, but the newer open PR covers the same fix with real behavior proof and is already the better canonical path for the remaining work.

Security review:

Security review cleared: The diff only propagates existing in-memory manifest metadata and adds local temp-dir tests; it does not touch dependencies, workflows, secrets, packaging, or external code execution sources.

What I checked:

• Current main omits contracts from bundled capability records: createCapabilityPluginRecord on current main accepts id/name/version/source/root metadata but has no contracts parameter and does not set record.contracts, so manifest-owned contracts are dropped on the bundled capability path. (src/plugins/bundled-capability-runtime.ts:131, 49e288823cda)
• Current main validates bundled tools against the missing field: The bundled capability runtime calls normalizePluginToolContractNames(record.contracts) before accepting captured tools, so missing record contracts make declared tool registrations look undeclared. (src/plugins/bundled-capability-runtime.ts:484, 49e288823cda)
• Normal plugin records preserve manifest contracts: The normal loader record helper accepts contracts?: PluginManifestContracts, seeds provider-like ID arrays from contracts, and stores contracts: params.contracts, showing the parity target for bundled capability records. (src/plugins/loader-records.ts:30, 49e288823cda)
• Documented contract expectation: The plugin manifest docs state that runtime api.registerTool(...) registrations must match contracts.tools, which makes the linked behavior a broken existing plugin contract rather than a new feature. Public docs: docs/plugins/manifest.md. (docs/plugins/manifest.md:662, 49e288823cda)
• This PR targets the right missing propagation: The PR diff adds PluginManifestContracts, carries contracts through createCapabilityPluginRecord, passes manifest.contracts, and adds focused declared/undeclared tool regression fixtures. (src/plugins/bundled-capability-runtime.ts:137, 222d72c3303d)
• This PR lacks real behavior proof: The PR body only says a local workflow batch passed and points to the test file; live PR checks show repeated Real behavior proof failures for this head SHA. (222d72c3303d)

Likely related people:

• vincentkoc: Current-main blame for the bundled capability record helper, bundled tool validation block, and loader-record contract field points to Vincent Koc in recent plugin-loader history. (role: recent area contributor; confidence: high; commits: 0668f1e003ed, 57f9a558e4e9, 1fc5b2b7032c; files: src/plugins/bundled-capability-runtime.ts, src/plugins/loader-records.ts)
• shakkernerd: The plugin tool manifest contract enforcement that rejects undeclared runtime tools appears in commit 7641783, which is central to this bug path. (role: feature-history contributor; confidence: high; commits: 7641783d6b0e; files: src/plugins/bundled-capability-runtime.ts, src/plugins/registry.ts, src/plugins/tool-contracts.ts)
• steipete: Recent plugin loader and manifest-registry commits in the provided review context touch the neighboring record construction and contract hydration surfaces. (role: adjacent area contributor; confidence: medium; commits: 4aedffd37aed, 06056926a099; files: src/plugins/loader-records.ts, src/plugins/manifest-registry.ts, src/plugins/registry.ts)

Codex review notes: model gpt-5.5, reasoning high; reviewed against 49e288823cda.