corrections: generator for consumer findings-buffer adapters #7565

Activity

1. kyle-sexton

   added

   needs-humanHuman-in-the-loop required; autonomous sessions must not resolve items carrying this.Human-in-the-loop required; autonomous sessions must not resolve items carrying this.

   on Oct 16, 2026
2. kyle-sexton

   added the

   Feature

   issue type on Oct 16, 2026
3. kyle-sexton

   added a parent issue on Oct 16, 2026

   • Epic: absorb Lauren Tan's and Matt Pocock's agent workflows (poteto-review) #7555
4. kyle-sexton

   set

   Work status

   to

   needs-spec

   on Oct 16, 2026
5. github-actions commented on Oct 16, 2026

   

   github-actionsBot

   on Oct 16, 2026 – with GitHub Actions

   Last edited by github-actions

   Contributor

   More actions

   Proposed work class: none

   Size: Medium
   Complexity: Medium
   Uncertainty: Knowable
   Flags: intent

   Understood: this is a parked item for a generator that scaffolds consumer findings-buffer adapters. It reopens only once a second consumer adapter exists. The choice among reusing /work-items:onboard-adapter, a sibling, or neither is still open.

   Open question:

   1. Which of the three options should the generator follow? RECOMMENDED: decide only after the trigger fires and the second adapter is cited. Until then, two real adapters can show what they share, and the issue stays parked.

   No likely duplicates found in the open issues list.

   _{Automated triage. A maintainer reviews it.}
6. github-actions

   added

   needs-triageNot yet classified. Floor until a type and one priority tier are set.Not yet classified. Floor until a type and one priority tier are set.

   on Oct 16, 2026
7. kyle-sexton

   added

   needs-specNeeds a Brief or plan before anyone can build it.Needs a Brief or plan before anyone can build it.

   and removed

   needs-triageNot yet classified. Floor until a type and one priority tier are set.Not yet classified. Floor until a type and one priority tier are set.

   on Oct 16, 2026
8. kyle-sexton

   removed

   needs-humanHuman-in-the-loop required; autonomous sessions must not resolve items carrying this.Human-in-the-loop required; autonomous sessions must not resolve items carrying this.

   on Oct 24, 2026
9. kyle-sexton commented on Oct 24, 2026

   

   kyle-sexton

   on Oct 24, 2026

   MemberAuthor

   More actions

   Released for re-triage under the owner's 2026-10-24 rule: an issue stops for a person only for an intent or vision question, a security call, a host or attended run, or spend outside prepaid credit. The hold label came off and intake triage runs again now; it re-applies a hold, with a numbered question, when one of those applies.

   To hold this issue again, add needs-human (or status: needs-decision) and say why in a comment.
10. github-actions

    added

    priority: mediumReal value, no hard deadline; normal backlog flow.Real value, no hard deadline; normal backlog flow.

    status: needs-decisionAwaiting a human or maintainer judgment call.Awaiting a human or maintainer judgment call.

    needs-triageNot yet classified. Floor until a type and one priority tier are set.Not yet classified. Floor until a type and one priority tier are set.

    on Oct 24, 2026
11. melodic-automation-lanes commented on Oct 24, 2026

    

    melodic-automation-lanesBot

    on Oct 24, 2026

    Contributor

    More actions

    Refinement. A read-only run explored this repository, searched its issues and pull requests, and read the allowed docs to draft what follows. It is model text, to check, not instructions.

    Intended outcome: When a second consumer findings-buffer adapter exists, a generator scaffolds new adapters, built by reusing /work-items:onboard-adapter, a sibling command, or neither.

    Related work

    • corrections: findings buffer with a local-file adapter #7574 (related): closed as completed; shipped the findings buffer and the local-file adapter, the only adapter so far (plugins/corrections/tools/findings-buffer/adapters/local-file)
    • corrections: OpenTelemetry read-back adapter for the findings buffer #7564 (related): open OpenTelemetry read-back adapter; could become the second adapter that fires the reopen trigger
    • corrections: findings-buffer Discussion sink (slice b of #7574) #9152 (related): open Discussion sink, slice b of #​7574; could also be the second adapter
    • feat(corrections): accept a repository-local findings-buffer adapter only from user scope #9059 (related): open; repository-local adapter acceptance, which bears on the adapter loading model a generator would target

    Open questions

    1. Is this issue to stay parked until a second consumer findings-buffer adapter exists, with no lane work now?
       RECOMMENDED: Yes: keep it parked. The trigger has not fired, since only the local-file adapter exists under plugins/corrections/tools/findings-buffer/adapters, so no unattended run can meet the done-when items. Basis: judgment
    2. Which option should the generator follow: reuse /work-items:onboard-adapter, a sibling command, or neither?
       RECOMMENDED: Decide after the second adapter lands, comparing the two real adapters. The onboard-adapter command is tied to the work-item-tracker adapter shape, so a sibling is the likelier fit, but this is the owner's call. Basis: judgment
    3. Which open issue counts as the second adapter that fires the trigger: #​7564 (OpenTelemetry read-back), #​9152 (Discussion sink), or either one?
       RECOMMENDED: Either one, once it is merged. Cite the merged pull request in a comment on this issue. Basis: judgment

    Sources read

    • plugins/corrections/tools/findings-buffer/adapters/local-file/capabilities.json: the only adapter directory found under the corrections findings buffer
    • plugins/work-items/tools/work-item-tracker/adapters/linear/capabilities.sh: onboard-adapter is referenced from the work-item-tracker adapter code, not the findings buffer
    • context.json: candidates #​7564 and #​9152 are open, so the trigger has not fired
    • context.json: no Decision recorded comment exists

    _{Automated refinement by the lanes App. Answer with a comment whose first line is **Decision recorded.**.}
12. kyle-sexton commented on Oct 27, 2026

    

    kyle-sexton

    on Oct 27, 2026

    MemberAuthor

    More actions

    Decision recorded. The owner answered in the Refinement and Issue Triage sessions (2026-10-25), deciding the open items below on the facts:

    go with whatever the facts/data/metrics + /discovery:research says and ensure we're aligned with SOLID, DRY/SSOT principles

    I should only ever be in the loop ONLY when necessary (intent/vision changed, something came up during implementation that impacts trajectory/alignment, OR a high security risk) - I've covered this all before

    This answers the questions in the lane's pushback (#7565 (comment)).

    1. Does this stay parked until a second consumer findings-buffer adapter exists?
       Decided: Yes. The owner accepted Q571's answer, which includes "no generator until a second consumer adapter exists" (.work/poteto-review/interview-checklist.md:616). The deferral table names the reopen trigger "a second consumer adapter exists" (.work/poteto-review/shared-understanding.md:357).
       The trigger has not fired. On origin/main (ecdba7a3a6), git ls-tree -d origin/main plugins/corrections/tools/findings-buffer/adapters/ lists one adapter, local-file, and git ls-tree -r --name-only origin/main | grep -i findings-buffer shows no findings-buffer.yaml binding file in the tree, so this repository declares no consumer adapter. The binding and repository-local adapter rules are in plugins/corrections/tools/findings-buffer/CONTRACT.md:114-134. No comment on the issue cites a second adapter.

    2. Which option should the generator follow (reuse /work-items:onboard-adapter, a sibling, or neither)?
       Decided: Not now. The body's "Done when" (corrections: generator for consumer findings-buffer adapters #7565) makes that choice after the trigger, when two real adapters can be compared.

    3. Which issue counts as the second adapter?
       Decided: Any merged consumer adapter, cited in a comment here. The OpenTelemetry read-back adapter (corrections: OpenTelemetry read-back adapter for the findings buffer #7564) is itself closed as a recorded deferral (decided-r26/7564.md:13), so it is not a near-term candidate.

    Closed as a recorded deferral. Reopen trigger: a second consumer findings-buffer adapter exists. When it does, reopen this issue, cite the adapter in a comment, record the choice among the three options, and file the slices under it, as the body's "Done when" says. Until then there is no lane work, so this record sets no - [ ] criteria. Close as not planned.
13. kyle-sexton

    closed this as not plannedon Oct 27, 2026