Hygiene: cross-ref rich-text attachments in recordable-subtypes plan#427
Hygiene: cross-ref rich-text attachments in recordable-subtypes plan#427jeremy wants to merge 3 commits into
Conversation
CloudFile and GoogleDocument are rich-text emitters; note that their absorption must carry their own `*_attachments` companion arrays so the rich-text projection coverage (rich-text-attachments-coverage) isn't silently missed when those subtypes land.
Spec Change Impact
|
There was a problem hiding this comment.
Pull request overview
This PR is a documentation hygiene follow-up to the rich-text *_attachments coverage work, adding a cross-reference reminder in the recordable subtypes absorption plan so future modeling of CloudFile / GoogleDocument doesn’t regress the now-complete rich-text attachment projection coverage.
Tip
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.
Changes:
- Add an explicit note that
CloudFile/GoogleDocumentmust include their own*_attachmentscompanion arrays when absorbed. - Link the note to
rich-text-attachments-coverageas the canonical reference for the projection-completeness requirement.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…tachments to #428 Copilot/human review on #427: the rich-text-attachments brief called #405 'this PR' and left the generic SearchResult attachments key untracked. #405 was the tracking issue; the merged PR is #408 (closes #405). Point the provenance at #408 and link the out-of-scope SearchResult.attachments bullet to its filed issue #428.
There was a problem hiding this comment.
All reported issues were addressed across 1 file (changes from recent commits).
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
Follow-up hygiene track after #408 (rich-text
*_attachmentscoverage).What
Adds a forward-looking cross-reference to
recordable-subtypes-doc.md:CloudFileandGoogleDocumentare rich-text emitters, so their eventualabsorption must carry their own
*_attachmentscompanion arrays — otherwisethe rich-text projection coverage completed in #408 would silently regress for
the newly-modeled subtypes.
Companion issue work (this track, not code)
Todomodel now carries all three fields it flagged(
completion_subscribers,comments_countvia Todos Update/Edit/Replace: merge-safe writes across all 6 SDKs #375;description_attachmentsvia Add description_attachments to the Todo model #400). Verified present in
go/pkg/basecamp/todos.go.Note: the retrospective mis-cited these as Todos.Update silently wipes omitted fields (partial PUT against replace-semantics endpoint) — all 6 SDKs; add Edit/Replace, make Update merge-safe #372; the actual PR is Todos Update/Edit/Replace: merge-safe writes across all 6 SDKs #375.
SearchResult.attachments— the generic aggregatedownloadable-files key (
searches/show.json.jbuilder:25) is aSearchResultfield, not a generic Recording field; unmodeled aggregate projection, low
demand.
modeled decode paths; already recorded as demand-gated in
rich-text-attachments-coverage.md.Verify
make validate-api-gapsclean (23 entries).Summary by cubic
Adds a cross-reference in
recordable-subtypes-doc.mdsoCloudFileandGoogleDocumentkeep their own*_attachmentsarrays when absorbed, preserving rich‑text coverage from #408. Also updatesrich-text-attachments-coverage.mdto point provenance to #408 (closes #405), standardize that phrasing, and link the out‑of‑scopeSearchResult.attachmentsto #428; closes #355.Written for commit f975a26. Summary will update on new commits.