Follow-up from the thermo-nuclear review round 2 (see PR #70 / tracking #73).
Location: frontend/packages/sdk-vue/src/use-project-counts.ts:31-39, 100-134
Issue: Inside the framework-generic @comtrya/sdk-vue package this composable hardcodes invokeOp("ext_issues", "issues", "list-issues", ...) and invokeOp("ext_epics", "epics", "list-epics", ...), a fixed TRACKED_TOPICS list of dev.comtrya.issues.*/dev.comtrya.epic.*, and duplicates backend status semantics (state === "CLOSED", "DONE"||"CANCELED" -> done, "IN_PROGRESS"||"AT_RISK" -> in-progress, else planned).
Why it matters: Violates the hard rule that the SDK/codegen path stay generic and never special-case a specific extension (issues/epics/pulls/checks), and the 'no backend-rule duplication' lens. The SDK now embeds issues/epics business logic; any change to epic state values or topic names on the backend silently diverges from this copy, and the generic package gains a build/runtime coupling to two specific extensions.
Proposed fix: Move this composable into the owning extension UI(s), or make it generic: accept the extension ids, op coordinates, tracked topics, and a state-classifier as parameters supplied by the caller. The generic package must not name ext_issues/ext_epics or encode their state vocabularies.
Follow-up from the thermo-nuclear review round 2 (see PR #70 / tracking #73).
Location:
frontend/packages/sdk-vue/src/use-project-counts.ts:31-39, 100-134Issue: Inside the framework-generic
@comtrya/sdk-vuepackage this composable hardcodesinvokeOp("ext_issues", "issues", "list-issues", ...)andinvokeOp("ext_epics", "epics", "list-epics", ...), a fixedTRACKED_TOPICSlist ofdev.comtrya.issues.*/dev.comtrya.epic.*, and duplicates backend status semantics (state === "CLOSED","DONE"||"CANCELED"-> done,"IN_PROGRESS"||"AT_RISK"-> in-progress, else planned).Why it matters: Violates the hard rule that the SDK/codegen path stay generic and never special-case a specific extension (issues/epics/pulls/checks), and the 'no backend-rule duplication' lens. The SDK now embeds issues/epics business logic; any change to epic state values or topic names on the backend silently diverges from this copy, and the generic package gains a build/runtime coupling to two specific extensions.
Proposed fix: Move this composable into the owning extension UI(s), or make it generic: accept the extension ids, op coordinates, tracked topics, and a state-classifier as parameters supplied by the caller. The generic package must not name
ext_issues/ext_epicsor encode their state vocabularies.