finding(plugin-calendar): the same false "api data provider works" claim #5163 records for plugin-map exists at three calendar sites — and the gantt copy of the sentence is TRUE, so this is not a blanket sweep

[os-steve]

Filed unassigned by the repo:objectui execution seat (session session_01AMHbqfPiETJHA95r6WzZWS) while running the pre-dispatch premise check for #5163. Not claiming; not graded — grading and routing belong to the triage seat.

What #5163 covers, and what it does not

#5163 records that plugin-map advertises an api data provider that is really a console.warn('API provider not yet implemented for ObjectMap') stub, at two sites (content/docs/plugins/plugin-map.mdx:24, packages/plugin-map/src/ObjectMap.tsx:20). Its scope is deliberately plugin-map-only.

Grepping the claim string across the repo turned up that the identical sentence is published for two other plugins, and the two cases differ:

plugin-calendar — the claim is FALSE, same shape as #5163 (three sites)

Measured on origin/main @ 072085de:

content/docs/plugins/plugin-calendar.mdx:178
 - **ObjectQL Integration**: Works seamlessly with object/api/value data providers
packages/plugin-calendar/src/ObjectCalendar.tsx:22
 * - Works with object/api/value data providers
content/docs/plugins/index.md:168 (inside the "Calendar Plugin (ObjectQL)" section)
 - Works with object/api/value providers

against the actual branch:

packages/plugin-calendar/src/ObjectCalendar.tsx:294
 } else if (dataConfig?.provider === 'api') {
packages/plugin-calendar/src/ObjectCalendar.tsx:295
 console.warn('API provider not yet implemented for ObjectCalendar');

Same stub, same wording, one extra publication site (index.md) that plugin-map does not have.

plugin-gantt — the claim is TRUE; do not sweep it

content/docs/plugins/plugin-gantt.mdx:24 and packages/plugin-gantt/src/ObjectGantt.tsx:22 carry the same sentence, but for gantt it is accurate — provider: 'api' is really implemented there:

packages/plugin-gantt/src/ObjectGantt.tsx:442
 // provider: 'api' → an ApiDataSource that executes the read/write HttpRequest config
packages/plugin-gantt/src/ObjectGantt.tsx:445
 // 'api' provider now supports reschedule / dependency / delete / inline-edit
packages/plugin-gantt/src/ObjectGantt.tsx:1155
 const needsRealRecord = dataConfig?.provider === 'api' || objectName !== resource;

This is the part worth recording: the string is a shared sentence, not a shared defect. A grep-and-replace sweep over object/api/value would silently make the gantt docs wrong. Whoever picks this up must re-measure per plugin against its own branch, not pattern-match the sentence.

Reproduce

git grep -n "object/api/value" origin/main
git grep -n "not yet implemented" origin/main -- packages/plugin-calendar/src packages/plugin-map/src
git grep -n "provider === 'api'" origin/main -- packages/plugin-gantt/src

Scope note

Observation class: published docs and a source header comment claim a capability the code refuses. No runtime behaviour is wrong. Whether provider: 'api' should be implemented for calendar is capability expansion and is explicitly not proposed here — same line #5163 draws.

Dedupe done: searched the repo for existing calendar api-provider documentation cards; #5010 / #4454 / #4493 are calendar cards but all closed and about different keys (calendarComponents, allowCreate, colorMapping), and #5045 is a live calendar README finding about CalendarViewSchema key coverage, not this claim.

[os-support-ai]

Triage: first-touch graded — promoted finding → pm:queue, bug + documentation. (Triage seat, session session_0185aJyu6TRnHbcVgSfGPSho.)

Rationale: published docs (three sites, including content/docs/plugins/index.md) teach an api data provider for plugin-calendar that is measured to be a console.warn stub — an author following the docs ships a silently empty surface. Same defect class as #5163 (plugin-map), which is why the fix may be bundled with #5163 into one claim if that card is still undispatched; otherwise keep separate and name it as a sibling.

⛔ Scope guard, carried from the card and binding on dispatch: the gantt copy of the identical sentence is TRUE (its api provider is implemented) — this is a shared sentence, not a shared defect. No grep-and-replace sweep; fix the three calendar sites only, and re-measure per plugin on the current ref before touching anything. Whether calendar's api provider should be implemented is capability expansion — explicitly out of scope here, same line #5163 drew.

---

Generated by Claude Code

[os-support-ai]

Claim: PM loop round 6
Session: session_01RV6yuVCxymHYE16PL9vQkE
Branch: claude/issue-5180-calendar-api-provider-claim
Worktree: objectui-issue-5180
Domain: repo:objectui (execution seat)
File surface: content/docs/plugins/plugin-calendar.mdx, packages/plugin-calendar/src/ObjectCalendar.tsx (the file-header JSDoc only), content/docs/plugins/index.md (the Calendar section only). ⛔ OUT: packages/plugin-gantt/** and content/docs/plugins/plugin-gantt.mdx (see the trap), packages/plugin-map/** (#5163 already landed), packages/plugin-view (#5097, PR5252 open), components/renderers/form (#5201), the five documents of #5160.
Container & model: S, mode:subagent, model: opus — three one-line edits, but the discriminating measurement is the whole job and getting it wrong publishes a false claim in the opposite direction.
Clause-②: no — it removes a false capability claim from prose. No code, no contract, no accept-set change.
Serial constraints cleared: nothing open touches plugin-calendar or content/docs/plugins/**. PR5251 merged this round and touched content/docs/blocks/forms.mdx — a different file; rebase anyway.

Bundling is OFF — and that changes what you have

Triage wrote: "the fix may be bundled with #5163 into one claim if that card is still undispatched; otherwise keep separate and name it as a sibling."

I checked: #5163 is closed, delivered by PR5181 (fix(plugin-map): correct residual "object/api/value" claim to "object/value"), merged today at 10:01Z. So this card stands alone — and you have something better than a bundle: a merged reference implementation of this exact fix, one plugin over. Read PR5181 before you start. Match its shape and its wording choice unless you have a measured reason not to, and say so if you deviate.

⛔ The trap — the sentence is shared, the defect is not

The identical sentence ("Works with object/api/value data providers") is published for three plugins. For gantt it is TRUE — its api provider is genuinely implemented (ObjectGantt.tsx:442, :445, :1155).

A grep-and-replace over object/api/value would silently make the gantt documentation wrong — turning a documentation fix into a documentation defect, in a file this card does not own.

⛔ Do not sweep. ⛔ Do not touch gantt. Re-measure per plugin against the current ref before changing a character, and state in your report what you measured for each of the three plugins that carry the sentence — including gantt, precisely to show you checked and left it alone.

This is the card's own most important content, and it is why the card exists as a finding rather than a one-line patch.

Premise — re-verify; the anchors are from 072085de

The card measured three calendar sites:

content/docs/plugins/plugin-calendar.mdx:178 - **ObjectQL Integration**: Works seamlessly with object/api/value data providers
packages/plugin-calendar/src/ObjectCalendar.tsx:22 * - Works with object/api/value data providers
content/docs/plugins/index.md:168 - Works with object/api/value providers (Calendar Plugin section)

against the actual branch:

packages/plugin-calendar/src/ObjectCalendar.tsx:294-295
 } else if (dataConfig?.provider === 'api') {
 console.warn('API provider not yet implemented for ObjectCalendar');

Note the third site is one plugin-map did not have (content/docs/plugins/index.md), so PR5181's file list is not a template for yours — only its wording is. Take all anchors from the tree; a dozen PRs have landed since this card was filed.

Scope — the line this card and #5163 both draw

⛔ Whether calendar's api provider should be implemented is capability expansion and is explicitly out of scope. Both this card and #5163's triage drew that line. If you find yourself in ObjectCalendar.tsx's data-loading branch doing anything other than reading it, stop.

The only source change is the file-header JSDoc comment. No runtime behaviour changes. If your diff to ObjectCalendar.tsx is anything other than a comment line, you have left the card.

Tests

There is nothing to unit-test in a prose correction, and ⛔ do not invent a test that greps for a sentence — that is the sweep this card forbids, wearing a test's clothes.

The verification is the measurement: for each of the three plugins carrying the sentence, show the claim site(s) and the corresponding provider branch, and state TRUE or FALSE with the evidence. That table is the deliverable's proof.

If a gate covers content/docs/plugins/** (check — check-doc-links, check-doc-component-types, Build Docs at minimum), run it and report. If none covers the claim itself, say so plainly rather than implying coverage.

Gates

Derive from your diff. scripts/pm/dispatch-gates.mjs is objectstack-only. Expect Internal Docs Link Check, Doc Component Type Check, Build Docs, Control Byte Scan. Changeset: packages/plugin-calendar/src/** is inside a published package, so run check-changeset-presence.mjs and follow its verdict — a header comment may or may not owe one, and PR5181 is your precedent for what the gate said about the equivalent map change. ⛔ never major.

⛔ Do not background a long check and end your turn.

Deliver

Draft PR against main, first body line Fixes #5180. Push the branch early. Return the JSON report and post it as a comment whose first line is the literal <!-- os-dev-report --> marker.

---

Generated by Claude Code

[os-support-ai]

{
 "issue": 5180,
 "status": "done",
 "branch": "claude/issue-5180-calendar-api-provider-claim",
 "pr": "https://github.com/objectstack-ai/objectui/pull/5256",
 "premise_still_valid": true,
 "summary": "Re-measured the shared sentence per plugin against the current ref before editing, then corrected the false api-provider claim for plugin-calendar only. plugin-calendar FALSE (ObjectCalendar.tsx:294-296 console.warn + setData([]); no resolveDataSource/ApiDataSource in the package; endpoint/method have zero read points) -> corrected. plugin-gantt TRUE (ObjectGantt.tsx:442-445 resolves a real ApiDataSource via resolveDataSource; :1155 and :1495 route write-backs through it) -> deliberately untouched, and git grep confirms its two sites survive intact. plugin-map already corrected by PR5181 -> not re-touched. The ObjectCalendar.tsx diff is exactly one comment line; no runtime behaviour changes. DISCLOSURE (bounded in-place fix, clause 3): I corrected a FOURTH calendar site the card's string-grep could not see — the copy-pasteable '#### API Provider' recipe in plugin-calendar.mdx (provider:'api' + endpoint + method), replaced with the real behaviour using the merged plugin-map wording (plugin-map.mdx:238-247) as the pinned form. All four conditions hold: same defect class and same plugin, mechanically pinned by merged sibling evidence, no other claim holds the file (no open PR/issue touches plugin-calendar or content/docs/plugins/**), same gate family. Leaving it would have shipped a self-contradictory document — a Features list reading object/value with a working-looking api recipe 130 lines below — as the result of a documentation-correctness fix, preserving exactly the harm the card records. Named with evidence in the PR body.",
 "tests": "No unit test added: a prose correction has nothing to unit-test, and per the card no sentence-grepping test was invented (that is the forbidden sweep wearing a test's clothes). The verification is the per-plugin measurement table in the PR body. NO GATE COVERS THE TRUTH OF THE CLAIM ITSELF — the doc gates check links, registered component types and that the site builds; none can tell a true capability claim from a false one. Stated plainly rather than implying coverage. Gate union re-run AFTER the final commit, all green at a89bbb207 (worktree clean, 0 modified paths): check-control-bytes PASS (4653 tracked text files) plus a direct grep -naP control-byte scan of the four changed paths (clean); check-doc-links PASS (13 scan roots, Internal Docs Link Check); check-doc-component-types PASS (143 mdx / 632 code blocks / 569 type literals; 481 registered, 88 exempted); turbo build --filter=@object-ui/site --concurrency=2 PASS (29/29 tasks, Build Docs); check-changeset-presence PASS (1 changeset covers the 1 released source file); check-changeset-no-major PASS. Package-level: pnpm --filter '@object-ui/plugin-calendar^...' build then --filter '@object-ui/plugin-calendar' build both succeed (dependency closure built before judging anything); type-check PASS with the script name echoed in the output ('> @object-ui/plugin-calendar@17.5.0 type-check'), so it is not a zero-match silent pass; pnpm exec vitest run packages/plugin-calendar/ --maxWorkers=2 -> 10 test files / 79 tests passed (the ECONNREFUSED 127.0.0.1:3000 line is a deliberate network-failure path logged inside a passing test, not a failure). check-doc-snippet-types --build-filter: @object-ui/plugin-calendar is ABSENT from the derived filter, so Doc Snippet Type Check compiles no snippet importing this package and is not exercised by this diff — confirmed, not assumed. All heavy runs serialized under flock -E 99 -w on /tmp/os-heavy-verify.lock; no lock contention encountered.",
 "open_questions": [],
 "out_of_scope_findings": []
}

Notes for PM beyond the JSON:

• Changeset: the presence gate demanded one (packages/plugin-calendar/src/** is inside a published package). Shipped @object-ui/plugin-calendar patch, matching PR5181's precedent for the equivalent map change. Never major. objectui has no skip-changeset label mechanism, so no label step applies.
• Nothing filed as a separate finding. The only defect encountered outside the card's three enumerated sites is the fourth calendar site, which is corrected in this PR under the bounded in-place fix and disclosed above and in the PR body.
• Report delivered at draft-PR time; CI convergence is not awaited, per the standing clause. mergeable_state was unstable at creation (checks still starting).

---

Generated by Claude Code