# Comparison report: Pebble Board Version 1 → Version 2 Scope: the two complete fictional guides in `source-versions.en.md`, including their headings and status list. Direction: Version 1 is old; Version 2 is new. O and N labels identify paragraphs in those versions. This report describes the text; it does not verify how software behaves or infer why the author made a change. ## What readers need to know Version 2 changes the workflow, content and delivery rules. Friday scheduling moves one hour earlier, board-owner review becomes optional, and the described update no longer includes card summaries. Internal-only cards acquire an inclusion exception. Cancellation after queuing and automatic retry are explicitly ruled out, and the resend instruction names the board owner rather than editors. The old two-minute receipt commitment is absent. Two actions are added: saving a recipient group and copying an update link after dispatch. The information-handling prohibition and recipient instructions move without changing their wording. The status list is reformatted; it does not gain a new status. Attached files remain excluded. ## Substantive changes ### C1 — Review becomes optional; sending is assigned to the editor Old, O03: “A workspace editor prepares the update. The board owner reviews it before it is sent.” New, N06: “A workspace editor prepares and sends the update. Board-owner review is optional.” The old sequence includes board-owner review before sending. The new wording makes that review optional and explicitly assigns both preparation and sending to a workspace editor. It does not make approval compulsory or say that the owner may no longer review an update. ### C2 — The Friday time moves earlier Old, O04: “Schedule the update for Friday at 16:00 UTC.” New, N07: “Schedule the update for Friday at 15:00 UTC.” The change is 16:00 → 15:00 UTC, one hour earlier on Friday. The text does not give an effective date for applying this revision to existing schedules. ### C3 — Card summaries are removed from the described contents Old, O09: “Each update includes the title, summary and status of every visible card.” New, N10: “Each update includes the title and status of every visible card. Summaries are not included.” Title and status remain. Summary inclusion changes to an explicit exclusion. This is a reduction in the described contents, not richer content or a formatting edit. ### C4 — Internal-only exclusion gains an exception Old, O10: “Cards marked Internal only are never included.” New, N11: “Cards marked Internal only are not included unless the editor switches on Include internal cards.” An absolute exclusion becomes an exclusion with an editor-controlled exception. The new sentence does not say the switch is on by default. Workspace-member access remains a separate rule in N03; this change does not establish public access. ### C5 — The preview description changes and loses an exact-card promise Old, O12: “The recipient preview lists exactly the cards that will be sent.” New, N13: “The preview shows the update title and number of selected recipients.” The described preview changes from an exact card list to a title and recipient count. The old assurance that the preview lists exactly the cards to be sent is no longer stated. The new sentence does not establish that a card list is impossible elsewhere in the interface; it cannot support continuing the old promise. ### C6 — Cancellation after queuing is prohibited Old, O13: “A scheduled update can be cancelled until dispatch begins.” New, N14: “A scheduled update cannot be cancelled after it is queued.” The old cancellation permission runs until dispatch begins. The new sentence prohibits cancellation after queuing. The guide does not define how queuing relates to the start of dispatch, so it does not support calculating how much earlier the cutoff is. It also does not expressly promise a particular cancellation procedure before queuing. ### C7 — The activity-log statement becomes exclusive Old, O14: “Delivery failures appear in the activity log.” New, N15: “Only failed deliveries appear in the activity log.” “Only” makes the new logging statement exclusive to failed deliveries. The old sentence said failures appear; it did not itself promise that successful deliveries appear. Do not describe this as proof that success entries used to exist and were removed. Read this change alongside the separately deleted receipt commitment below. ### C8 — The two-minute receipt commitment is deleted Old, O15: “Every selected recipient receives a delivery receipt in the activity log within two minutes.” New: no corresponding commitment appears anywhere in Version 2. Version 2 no longer states that every selected recipient receives a receipt in the activity log within two minutes. The report must not carry that promise forward as unchanged. Its deletion does not establish that receipts never occur or identify a replacement delivery time. ### C9 — Automatic retry is explicitly ruled out Old, O16: “The system retries a failed delivery once.” New, N16: “The system does not retry a failed delivery automatically.” The old system retry is no longer promised. The new guide explicitly says there is no automatic retry. This does not prohibit a manual resend; that instruction appears separately in N17. ### C10 — The resend instruction changes the named actor Old, O17: “Editors can resend a failed update from the activity log.” New, N17: “The board owner can resend a failed update from the activity log.” The named actor changes from editors to the board owner. Version 2 no longer grants editors that action in its text. It does not say “only the board owner,” so the comparison should not invent a complete software permission matrix or claim that an owner who is also an editor cannot act. ## Additions ### C11 — Saving a recipient group Old: no corresponding instruction appears in Version 1. New, N18: “Editors may save a recipient group on the board for use in later updates.” Version 2 adds a reusable recipient-group action for editors. It does not describe automatic sending, automatic group updates or any change to membership requirements. ### C12 — Copying an update link after dispatch Old: no corresponding instruction appears in Version 1. New, N19: “The confirmation screen shows a Copy update link action after dispatch.” Version 2 adds an action and its location/timing: the confirmation screen after dispatch. It does not make the link public. N03 still limits opening an update to workspace members. ## Movement and formatting without a substantive change | Location change | Exact text or labels in both versions | Assessment | | --- | --- | --- | | O19 → N02; Handling information moves near the beginning | “Do not include passwords, access tokens or personal contact details in an update.” | Pure move. The prohibition is retained, not deleted. | | O02 → N03; access text moves from Purpose and access into Access and recipients | “Only workspace members can open an update; this guide does not cover public links.” | Regrouping under a new heading; no change to this rule. | | O07 → N04; recipient instructions move before preparation | “Updates go to the recipients selected on the board.” | Pure move; selected recipients still determine distribution. | | O08 → N05; same section move | “Recipients may be added or removed until the editor selects Share update.” | Pure move; this editing boundary is unchanged. It is distinct from cancellation of an already scheduled update. | | O18 → N20; inline text becomes a bullet list | Old: “Status labels: Draft; Ready; Sent.” New heading text: “Status labels:” with bullets “Draft”, “Ready”, “Sent” | Format only. Ready was already present. There is no added or deleted status. | Purpose and access becomes Purpose, and the access material is regrouped as shown above. Reuse and sharing is a new heading for C11–C12. Heading changes do not create extra functional changes beyond the paragraphs they organize. No paragraph is both moved and substantively rewritten in this example. ## Other unchanged content | Old → new | Exact sentence retained | | --- | --- | | O01 → N01 | “Use this guide to prepare and share an internal project update from Pebble Board.” | | O05 → N08 | “Saved drafts remain available for 30 days after their last edit.” | | O06 → N09 | “Drafts can be discarded without sending an update.” | | O11 → N12 | “Attached files are not included.” | | O20 → N21 | “For a missing update, send the update ID and dispatch time to the workspace help channel.” | All 20 old paragraph blocks and all 21 new paragraph blocks are accounted for above. There are ten substantive changed/deleted items (C1–C10), two additions (C11–C12), four unchanged moved/regrouped blocks and one reformatted block, plus five other unchanged blocks. These are report items, not a count of individual software changes. ## Review handoff When working from Version 2, use Friday 15:00 UTC in this fictional guide; treat board-owner review as optional; exclude summaries and attachments; and check the internal-card exception rather than assuming “Internal only” always prevents inclusion. Do not rely on the old exact-card preview or two-minute receipt commitment. Plan recovery without an automatic retry and follow the new board-owner resend instruction. Ask the document owner when the new Friday time applies to existing schedules, how queuing relates to dispatch, and what receipt or completion evidence readers should now use. These are open questions, not inferred answers. The comparison does not authorize sending an update or changing any real process.