Skip to content

Comments

fix: infer projectId from session prefix to fix merge button#99

Open
AgentWrapper wants to merge 2 commits intomainfrom
fix/infer-project-id
Open

fix: infer projectId from session prefix to fix merge button#99
AgentWrapper wants to merge 2 commits intomainfrom
fix/infer-project-id

Conversation

@AgentWrapper
Copy link
Collaborator

Summary

  • Add inferProjectId() function that matches session ID prefix against configured sessionPrefix values (e.g. ao-18 matches prefix ao), with fallback to the only configured project when there's just one
  • Use it in metadataToSession() so legacy sessions (missing project field) get their projectId resolved automatically
  • Use it in the merge API route as a fallback when session.projectId doesn't resolve to a configured project
  • Improve dashboard error display — show user-facing alert() with parsed JSON error responses and formatted merge blockers list instead of console-only logging

Fixes the merge button failing with "No SCM plugin configured" for legacy sessions that don't have a project metadata field.

Successor to #46, which was closed due to the hash-based architecture refactoring in #58.

Test plan

  • 5 new unit tests for inferProjectId() (prefix matching, single-project fallback, no match, empty config, integration with list())
  • All 219 core tests pass
  • Build passes (including web package)
  • Typecheck clean
  • Manual test: create a session without project field in metadata, verify merge button works

🤖 Generated with Claude Code

Add inferProjectId() that matches session ID prefix against configured
sessionPrefix values (e.g., "ao-18" matches prefix "ao"), with fallback
to the single configured project. Used in metadataToSession() for
legacy sessions missing the project metadata field.

Also fix the merge API route to try prefix inference when project lookup
fails, and improve Dashboard merge error handling to show structured
error details (blockers, context) via alert() instead of console-only.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Three config generation design fixes:

1. worktreeDir was written by `ao init` and in the example but stripped
   by Zod (not in schema) and never passed to the workspace plugin
   (extractPluginConfig was a stub). Now:
   - Added worktreeDir to OrchestratorConfigSchema (default: ~/.worktrees)
   - Added worktreeDir to OrchestratorConfig interface
   - Implemented extractPluginConfig for workspace:worktree to pass
     worktreeDir through to the plugin

2. dataDir was written by `ao init` and in the example but stripped by
   Zod and paths.ts hardcodes ~/.agent-orchestrator unconditionally.
   Removed the dead field from ao init and the example file.

3. Default notifiers in DefaultPluginsSchema were ["composio", "desktop"]
   but ao init generates ["desktop"] and the example shows [desktop].
   The default notificationRouting also routed warning/info to composio,
   silently failing on any install without composio configured. Aligned
   all defaults to ["desktop"] only.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Copy link

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.

urgent: ["desktop"],
action: ["desktop"],
warning: ["desktop"],
info: ["desktop"],
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New worktreeDir path field not expanded by expandPaths

Low Severity

The new worktreeDir config field defaults to "~/.worktrees" via the Zod schema, but expandPaths only expands ~ in project.path values — it doesn't expand config.worktreeDir. This means config.worktreeDir retains the literal ~ prefix after config loading, unlike every other path field. The worktree plugin happens to do its own expandPath internally, so it works today, but any future code using config.worktreeDir directly for filesystem operations would silently create a directory literally named ~ instead of resolving to the home directory.

Additional Locations (1)

Fix in Cursor Fix in Web

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