Conversation
The Direct Messages composer's enabled state in `DMThreadView` is gated
entirely on the thread response's `isMutual` / `isBlocked` fields, both
optional in `DMThreadResponse` and defaulting to `false` when absent. A
server- or DTO-side drift that dropped or renamed either field would
silently gray the composer for genuine mutual followers.
Add an env-gated live contract test (mirrors the existing timeline/sign-in
contract tests): sign in, read the mutual-follower recipient set, and for
the first recipient assert `GET /api/dm/thread/{username}` decodes with the
mutuality fields present and coherent (`isMutual == true`, `isBlocked ==
false`, `otherUser.username == target`). Skips when creds are absent or the
account has no recipients. Never logs the token, usernames, or bodies.
Verified live against the API today: the server sends `isMutual:true` for a
mutual recipient and the DTO decodes it correctly — ruling out a client
mapping bug as the cause of a grayed composer.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VowMU43srLNDDrovoH1s2X
…h 2026-09-02 Reconcile the master plan against dev after PRs #12-#14 merged since the 2026-08-15 consolidation: - refresh test baseline to verified 2026-09-02 counts (Kit 317 / Domain 628 / Persistence 135; App target ** TEST SUCCEEDED **), from the stale 08-16 numbers - record sharing collaborators/invites/visibility (PR #13) and timeline cross-post destination links (PR #14) in "already shipped" - mark G4 GitHub issues as client-shipped (PR #12); note the issue update/comment routes remain backend-blocked on P1-H2 - add "Merged since consolidation" + "Where we are now" notes and a §1 "effectively done" banner: client-side parity is exhausted, next lever is §3 release engineering - flag that main is 30 commits behind dev; catch up before a release cut Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MQCieButVmc4o7KC6wWzEq
Fixes the broken "add a new row" flow on GitHub-backed lists. The client could not tell a list was GitHub-backed at all: every GitHub affordance keyed off the list-level `OwnedList.gitHubSource`, which the mapper hardcodes to nil and the wire `ListDTO` never carries — so the GitHub issue browser was permanently unreachable and the generic "Add Row" button (a native empty-row POST) was shown on lists whose rows actually sync from GitHub, where that create doesn't belong. Per the recon in work-consolidation.md P3-C, the live backing signal is row-level (`source`/`githubRepo`), not list-level. This models those fields end to end and derives backing from the rows: - Kit: `ListRowDTO` gains optional `source` + `githubRepo` (tolerant — native rows and existing fixtures decode unchanged). - Domain: `ListRow` carries them with an `isGitHubBacked` helper; the row mapper threads them through. - App: `ListRowsViewModel` derives `isGitHubBacked` / `gitHubRepo` from its loaded rows and guards `addRow()` to a no-op on backed lists. The rows-pane toolbar swaps "Add Row" for "New Issue" (opening the already built `GitHubIssuesView` → live `POST /api/github/issues`), disables native delete on backed lists, and the previously-dead top-level "Issues" button is finally reachable via the row-derived repo. Known limitation (documented in code): a GitHub-backed list with no rows loaded yet reads as not-backed until a synced row appears — there is no earlier signal until the backend surfaces a list-level `githubSource` (P3-C). Data-entry UX for plain lists (new-row composer, batched edits) is deliberately out of scope here and lands in a follow-up. BDD quartet across layers: DTO decode (synced/native), row mapping (backed/native/source-only), and view-model detection + Add Row guard. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YDGjkG777qZwS96khLPRdQ
…test test(dm): guard DM thread isMutual/isBlocked contract against drift
…n-plan docs(plan): sync work-consolidation.md with merged parity work (through 2026-09-02)
…uting feat(lists): detect GitHub-backed lists from rows and route to Issues
Back-merges the 9 parity commits that landed directly on `main` (G4/G7/G14 GitHub + timeline work) into `dev` so the `dev → main` release PR (#15) stops conflicting and can merge. Four files conflicted; all resolved by keeping `dev`'s side, which is the newer/superset in every case: - App/Features/Lists/OwnedListsRootView.swift — dev's row-derived GitHub repo expression is a superset of main's list-level-only check (PR #18). - App/Features/Documents/DocumentsRootView.swift — dev adds the Sharing toolbar (People / Invite by Email / Make Public) + sheets; main lacked them. - Packages/InterlinedPersistence/.../SwiftDataMessageStore.swift — dev's eager, region-isolated hydration (Swift 6 strict concurrency) supersedes main's closure that captured the ModelContext. - work-consolidation.md — took dev's consolidated master planning doc. main's non-conflicting additions were preserved via auto-merge. Verified on the merged tree: BUILD SUCCEEDED; App tests 632/0; Kit 319/0; Domain 631/0; Persistence 135/0; Decision-0003 import guard clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YDGjkG777qZwS96khLPRdQ
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Plan / wave reference
Path ownership
Packages/InterlinedKit/**,Packages/InterlinedDomain/**,Packages/InterlinedPersistence/**per agent (or one App feature folder)PLAN.mdorORCHESTRATION.md(read-only)Tests
test_givenX_whenY_thenZ)swift test --package-path Packages/<pkg>passes locallyxcodebuild -scheme InterlinedList -destination 'platform=macOS' build testpasses locallyDocs
docs/api-coverage.mdupdated if endpoint coverage changeddocs/progress.mdupdated if a wave gate moveddocs/decisions/if architecture changed