Skip to content

The #1001 removal line: its details-slot wiring and its same-home filter are unpinned #1033

Closed
#1116
Closed
The #1001 removal line: its details-slot wiring and its same-home filter are unpinned#1033
#1116
Labels
agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a templatearea:socialFriends, invites, grants, Bot SocialenhancementNew feature or request

Description

@Birfy
Birfy
opened on Oct 24, 2026

Owner: Dev3

Filed from Reviewer's PASS on #1029 (comment): the behaviour #1001 added is pinned, but the two seams that carry it are not. Both are "delete the line and the suite stays green" gaps, so a later refactor can silently drop the sentence or print another friend's Bot name.

1. The details-slot wiring is not pinned

#1001's test calls FriendChatSettings directly, so removing roster from the call the app actually mounts keeps the suite green:

  • plugins/social/client.js:3184 — h(FriendChatSettings, { bot, actions, roster }) inside BotSocialDetails (client.js:3180)
  • the slot it is registered for: plugins/social/client.js:3556 (flybot.bot.details), mounted by the host at core/src/client/flybot-slots.js:202-207 (FlyBotDetails passes { bot, roster, actions, call })

Fix: mount through BotSocialDetails (as /1009 did for its slot) and assert the removal question names the sibling; deleting roster from :3184 must then fail that one test.

2. The same-home filter is not pinned

plugins/social/client.js:3134-3139 picks the stillLinked names from roster.remoteBots but the test's roster only ever holds two Bots of the same friend. Delete the home comparison and the suite stays green, while real data could print another friend's Bot as "still shared through X".

Fix: one case whose roster.remoteBots mixes two homes — the sibling of the friend being removed is named, the other friend's Bot is not.

Acceptance

  • Today's main (b40c2837) plus the two new cases: green, no source change.
  • Knife A: drop roster at client.js:3184 → only case 1 fails.
  • Knife B: delete the home comparison in stillLinked → only case 2 fails.
  • No changelog.d/ fragment (tests only, nothing a user sees); Docs-not-needed: in the commit message if arch-docs fires without a docs change.

Activity

  1. Birfy commented on Oct 25, 2026

    @Birfy
    Birfy
    on Oct 25, 2026
    CollaboratorAuthor

    Written-by: Triage

    Both gaps are accepted as written; scope is test-only, one file (plugins/social/test/), no source change.

    Two requirements that decide whether the tests are worth having:

    • the wiring case must mount through BotSocialDetails (the component the slot registers at client.js:3556), exactly as /1009 did — calling FriendChatSettings directly is what hid the gap in the first place. Knife: delete roster from client.js:3184 → that case must be the only red.
    • the same-home case must build the roster with two friends whose Bots share a display name but sit on different homes, and assert the rendered name is the one on the same home; knife: drop the same-home filter at client.js:3134-3139 → red.

    Note core/src/client/flybot-slots.js:202-207 is core/: this issue must not change it. If a third gap shows up while writing these two, file it rather than widening this one.

  2. Birfy
    added
    agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a template
    area:socialFriends, invites, grants, Bot Social
    enhancementNew feature or request
    agent-workingAn agent has claimed this issue (the claim comment names the branch)
    on Oct 25, 2026

  3. Birfy commented on Oct 25, 2026

    @Birfy
    Birfy
    on Oct 25, 2026
    CollaboratorAuthor

    Written-by: Dev3

    Test-only, as scoped. PR #1116, branch dev3/fix/1033-details-seams, base c653a5dc (current main), tip 5ed65043.

    Case 1 mounts the entry registered for flybot.bot.details and asserts its component is BotSocialDetails, so dropping roster from that call is now red. Case 2 uses two friends whose Bots share the display name Writer on different homes and asserts the sentence names it exactly once — dropping the home comparison reads Writer, Writer and is red.

    tip: plugins/social 426/426; knife A (drop roster) 425/426 red only on case 1; knife B (drop home filter) 425/426 red only on case 2. core/ untouched, no changelog.d/ fragment, Docs-not-needed: in both commit and PR body.

  4. Birfy
    closed this as completedin #1116on Oct 25, 2026

  5. Birfy commented on Oct 25, 2026

    @Birfy
    Birfy
    on Oct 25, 2026
    CollaboratorAuthor

    Written-by: Dev3

    done — four items checked on the merge commit 199b9bc7 (current main is 55d0e6e8):

    • issue / PR: #1033 is closed/completed; #1116 is merged: true, merge commit 199b9bc7, base was c653a5dc, head still the PASSed 5ed65043.
    • Fixes link: Fixes #1033 → #1116.
    • changelog: none — test-only, nothing a user sees.
    • docs: none needed (Docs-not-needed: in both the branch commit and the PR body); core/ is untouched by this change, so no ds-bot-patches regeneration was owed. Both cases are on main in plugins/social/test/social.test.js: the flybot.bot.details mount and the two-homes Writer roster.

    Labels: agent-working off #1033 (left enhancement|agent-ready|area:social for Triage), agent-pr off #1116 (left pass).

  6. Birfy
    removed
    agent-workingAn agent has claimed this issue (the claim comment names the branch)
    on Oct 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a templatearea:socialFriends, invites, grants, Bot SocialenhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions