Skip to content

Tree: model-based clustering for roles the rules cannot place (#450 item 2) #519

Closed

Description

@HugoXK

What

Part of #450 (item 2, model-based clustering). Today the tree places a Bot by the words in its name, role label and description (src/roles.js). A role the small vocabulary does not hold — a job title, a brief in another language — finds no group and the Bot stays outside the tree.

Expected behavior

  • modelClassify: true in the tree config, together with the host allowing flybot-tree in flybot.modelPlugins, asks the sanctioned plugin model call (Add a sanctioned, capped model call for plugins #518) for a single category when the rules find none.
  • The answer is stored on the Bot (modelDomain) and read by roles.js only where the vocabulary placed nothing, so the rules stay primary.
  • One call per role change (fingerprinted); a refused or unparsable answer stores nothing and never clears a good label; the host's own caps bound every call.
  • Off by default; without the host seam nothing is asked.

Change scope

New plugins/tree/src/classify-model.js; plugins/tree/src/roles.js (reads a stored modelDomain), plugins/tree/src/organize.js (feeds it), plugins/tree/src/adapter.js (askModel, feature-detected), plugins/tree/index.js (opt-in wiring), tests plugins/tree/test/classify-model.test.js + the mock's model.ask, docs/subsystems/tree.md, README. Plugin only; the plugin degrades to the current rules when the model seam is absent.

Why

The tree's differentiator is "the team organizes itself"; a model category lets it group by meaning, not only keywords — the missing half of #450 item 2.

Activity

  1. Birfy commented on Oct 20, 2026

    @Birfy
    Collaborator

    Triage (2026-10-20 16:05 Asia/Shanghai): HugoXK's PR #520 implements this (#450 item 2) — opt-in modelClassify, stores modelDomain, rules stay primary, depends on the sanctioned plugin model seam in #518.

    Labeled enhancement + area:automation. Not applying agent-ready: HugoXK owns the PR, and the owner has not confirmed accepting #520 as the model-clustering slice.

    Confirmation item for the owner: accept HugoXK #520 (with #518) as the #450 model-clustering slice?

  2. added
    agent-workingAn agent has claimed this issue (the claim comment names the branch)
    on Oct 20, 2026
  3. Birfy commented on Oct 20, 2026

    @Birfy
    Collaborator

    Triage: an implementation PR is already open — #520 ("Tree: model-based clustering for roles the rules cannot place"), so this issue is agent-working while that PR waits.

    The PR builds on #518 (the sanctioned, capped model call), so it can only be re-checked after #518 is merged; its head has not moved since 2026-10-20 15:06 and it needs main merged in before it can be reviewed again.

  4. Birfy commented on Oct 21, 2026

    @Birfy
    Collaborator

    Implemented by PR #520 (merged as f8931346, 2026-10-21 01:55Z): opt-in model-based clustering through the sanctioned plugin model call (#518) — modelClassify + host allow-list, one ask per role-text fingerprint, rules still primary, category stored on the Bot.

    The PR body did not carry Fixes #N, so GitHub did not auto-close this issue. Closing by hand with that evidence.

  5. removed
    agent-workingAn agent has claimed this issue (the claim comment names the branch)
    on Oct 21, 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

    area:automationScheduled tasks and automationenhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions