Skip to content

pr/2849ed174 refresh work item hierarchy on tool even#324

Merged
plusplusoneplusplus merged 8 commits into
mainfrom
pr/2849ed174-refresh-work-item-hierarchy-on-tool-even
Jun 12, 2026
Merged

pr/2849ed174 refresh work item hierarchy on tool even#324
plusplusoneplusplus merged 8 commits into
mainfrom
pr/2849ed174-refresh-work-item-hierarchy-on-tool-even

Conversation

@plusplusoneplusplus

Copy link
Copy Markdown
Owner
  • Refresh work item hierarchy on tool events
  • Remove obsolete update-work-item bundled skill
  • Compact work item detail header
  • feat(dream): bundle analyzer/critic system prompts as the dream skill (AC-01/03 foundation)
  • feat(dream): source analyzer/critic system prompts from the dream skill (AC-02/04/05)
  • fix(coc): persist ask mode in pr-classification process metadata
  • Add unified task-group framework for hierarchical tasks

plusplusoneplusplus and others added 7 commits June 12, 2026 15:06
…ll (AC-01/03 foundation)

Move the dream analyzer and critic system prompts into a single bundled
`dream` skill (SKILL.md with `## Section: analyzer` and `## Section: critic`)
and add the server-side resolution plumbing, ahead of deleting the inline
constants in a follow-up.

- Add packages/forge/resources/bundled-skills/dream/SKILL.md, generated
  byte-for-byte from ANALYZER_SYSTEM_PROMPT / CRITIC_SYSTEM_PROMPT; the one
  analyzer interpolation becomes a `{{dreamCardCategories}}` placeholder.
- Register `dream` in BUNDLED_SKILLS_REGISTRY.
- Add a generic `extractSkillSection` `## Section:` extractor in forge,
  exported from the skills barrel.
- Add a dream prompt resolver (coc) that resolves the skill section text and
  fills the categories placeholder from DREAM_CARD_CATEGORIES.
- AC-03 parity test asserts the resolved analyzer/critic prompts equal the
  former constant text (fixture captured from source), plus forge unit tests
  for the extractor and the bundled skill structure.

Constants are still in use; AC-02 (rewire + delete) follows.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ll (AC-02/04/05)

Complete the dreaming-prompts-to-skill refactor on top of the AC-01/03
foundation:

- AC-02: delete the inline ANALYZER_SYSTEM_PROMPT / CRITIC_SYSTEM_PROMPT
  constants. analyzeDreamConversations now takes a DreamSystemPromptResolver
  and passes the resolved skill-section text as the systemPrompt. The resolver
  is threaded DreamRunExecutor -> routes/index.ts, where dataDir is known, via
  resolveDreamSystemPrompt(section, { dataDir }). grep finds no remaining
  constant references.
- AC-04: attachDreamStepMetadata now records dreamStep.skill =
  { name: 'dream', section }; posture flags (readOnly, toolsEnabled:false,
  mcpEnabled:false, permissionPolicy:'deny-all') are unchanged. The persisted
  dream-step metadata is now typed via a new DreamStepContext interface
  (with DreamStepSkillProvenance) in dream-internal-process.ts.
- AC-05: add 'dream' to DEFAULT_BUNDLED_SKILLS so the skill auto-installs into
  ~/.coc/skills on startup; no pre-flight guard.
- AC-06: existing dream tests updated to pass a resolver and assert skill
  provenance; new AC-05 containment test. coc/forge build, tsc --noEmit, lint
  (0 errors), and dream + config test suites are green.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
pr-classification tasks run read-only ask mode in ClassificationExecutor,
but the process-lifecycle runner only recorded `metadata.mode` for chat
payloads. With the field absent, dashboard surfaces fell back to labelling
the process 'autopilot' even though it executed read-only.

Record `mode: 'ask'` for pr-classification payloads so the persisted
metadata reflects the real execution mode and the UI stops mislabelling it.

Add regression coverage asserting classification tasks persist mode 'ask'
(metadata + seeded user turn), chat tasks keep their explicit mode, and
unrelated non-chat tasks leave mode undefined.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Consolidate the four bespoke parent/child task implementations (For Each,
Map Reduce, Ralph, Dreams) onto one shared framework:

- forge: generic task-group registry (task_groups + task_group_members,
  schema v22) with SqliteTaskGroupStore over the shared database handle.
- coc server: TaskGroupService + GET /api/workspaces/:id/task-groups;
  every child task carries a generic payload.context.taskGroup tag
  (groupId/groupType/role/itemKey) mirrored into process metadata and
  history items; feature stores fire change hooks projected into the
  registry by feature-sync (Ralph via a dataDir-keyed session-change
  listener); idempotent startup backfill projects pre-framework
  runs/sessions; group pins accept open type strings.
- Feature adoption: For Each and Map Reduce runs, Ralph sessions
  (iterations + final checks now persist child links), and Dream runs
  (hidden linkage-only groups for analyzer/critic internals).
- coc-client: taskGroups domain + contracts; ProcessGroupPinType opened.
- SPA: shared task-group-grouping engine + per-type descriptor registry
  + unified TaskGroupRunRow; for-each/map-reduce grouping modules become
  engine adapters and their rows thin display wrappers; ralph grouping
  shares the helpers and resolves sessions from the generic tag too.

Behavior-preserving for existing UI (all prior grouping/row tests pass
unchanged); new framework layers covered by forge store, REST, feature
sync, backfill, and client engine tests.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
… and taskGroup context key

- Add realtimeRevisionByRepo: {} to useWorkItems mocks in
  WorkItemImportFromGitHub and WorkItemsTab.remote-provider tests
- Harden WorkItemHierarchyTree to use optional chaining on
  realtimeRevisionByRepo access
- Update ralph-start-routes test to expect ['ralph', 'taskGroup']
  context keys after the unified task-group framework addition

Co-authored-by: Cursor <cursoragent@cursor.com>
@plusplusoneplusplus plusplusoneplusplus merged commit 6533f92 into main Jun 12, 2026
36 checks passed
@plusplusoneplusplus plusplusoneplusplus deleted the pr/2849ed174-refresh-work-item-hierarchy-on-tool-even branch June 12, 2026 15:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant