chore: add /cap-build-process Claude slash command#102
chore: add /cap-build-process Claude slash command#102Kronprinz03 wants to merge 1 commit intomainfrom
Conversation
Adds a Claude Code slash command at .claude/commands/cap-build-process.md that gives users expert guidance on setup, annotations, errors, and autonomously checks deployed SBPA processes via the hybrid binding.
SummaryThe following content is AI-generated and provides a summary of the pull request: Add Claude Slash Command for
|
![hyperspace-insights[bot]](https://avatars.githubusercontent.com/u/2531208?s=60&v=4){kind=small}
There was a problem hiding this comment.
The PR adds a useful Claude slash command for @cap-js/process, but contains several correctness issues: the generic ProcessService code examples use the wrong event dispatch method (send instead of emit for lifecycle events) and include an incorrect businessKey field in the start payload, the typed service start signature needs verification against the actual generated API, and the grep pattern for finding local process IDs would silently produce empty results — breaking the cross-reference table in Step 5.
PR Bot Information
Version: 1.20.37
- File Content Strategy: Full file content
- Correlation ID:
dbc166bc-3405-403f-8906-90b046a10d7e - Event Trigger:
pull_request.opened - LLM:
anthropic--claude-4.6-sonnet
| await svc.emit('start', { | ||
| definitionId: 'eu12.myorg.myproject.processId', | ||
| context: { orderId: '123' }, | ||
| businessKey: 'ORDER-123' | ||
| }) |
There was a problem hiding this comment.
Bug: start on the generic ProcessService must use emit, but cancel/suspend/resume must also use emit — however the start payload shape is wrong.
Looking at the actual BTPProcessService.cds and BTPProcessService.ts, the start event expects { definitionId, context } — not a top-level businessKey field. The businessKey is passed as a messaging header (third argument to cds.queued(...).emit), not in the payload body. The example shown here incorrectly puts businessKey inside the payload object.
Should be:
await svc.emit('start', {
definitionId: 'eu12.myorg.myproject.processId',
context: { orderId: '123' }
})The businessKey in the outbox header is handled internally by the plugin and is not a user-supplied field in this call.
| await svc.emit('start', { | |
| definitionId: 'eu12.myorg.myproject.processId', | |
| context: { orderId: '123' }, | |
| businessKey: 'ORDER-123' | |
| }) | |
| // Start (async, via outbox) | |
| await svc.emit('start', { | |
| definitionId: 'eu12.myorg.myproject.processId', | |
| context: { orderId: '123' } | |
| }) |
Double-check suggestion before committing. Edit this comment for amendments.
Please provide feedback on the review comment by checking the appropriate box:
- 🌟 Awesome comment, a human might have missed that.
- ✅ Helpful comment
- 🤷 Neutral
- ❌ This comment is not helpful
| }) | ||
|
|
||
| // Cancel | ||
| await svc.emit('cancel', { businessKey: 'ORDER-123' }) |
There was a problem hiding this comment.
Bug: cancel, suspend, and resume on the generic ProcessService are events (not actions), so they must also be dispatched with emit, not send. The CDS service definition (BTPProcessService.cds) declares them as event, and the implementation uses cds.queued(processService).emit(...). Calling svc.send('cancel', ...) would attempt a synchronous action invocation and fail at runtime.
Consider changing all three lifecycle operations to use emit:
await svc.emit('cancel', { businessKey: 'ORDER-123' })
await svc.emit('suspend', { businessKey: 'ORDER-123' })
await svc.emit('resume', { businessKey: 'ORDER-123' })| await svc.emit('cancel', { businessKey: 'ORDER-123' }) | |
| // Cancel | |
| await svc.emit('cancel', { businessKey: 'ORDER-123' }) | |
| // Suspend | |
| await svc.emit('suspend', { businessKey: 'ORDER-123' }) | |
| // Resume | |
| await svc.emit('resume', { businessKey: 'ORDER-123' }) |
Double-check suggestion before committing. Edit this comment for amendments.
Please provide feedback on the review comment by checking the appropriate box:
- 🌟 Awesome comment, a human might have missed that.
- ✅ Helpful comment
- 🤷 Neutral
- ❌ This comment is not helpful
| import { MyProcessService } from '#cds-models/MyProcessService' | ||
|
|
||
| const svc = await cds.connect.to(MyProcessService) | ||
| await svc.start({ orderId: '123', amount: 500 }) |
There was a problem hiding this comment.
Bug: The typed service start method signature is wrong. Looking at processService.ts, the typed service's start handler receives req.data.inputs (not top-level named fields). The inputs object is what gets forwarded as context. The call svc.start({ orderId: '123', amount: 500 }) implies flat named parameters are the API, but the actual typed service generated after cds import wraps them under inputs. Verify the generated typed API before documenting this signature — it may need to be svc.start({ inputs: { orderId: '123', amount: 500 } }) or similar, depending on the generated CDS action signature.
Please provide feedback on the review comment by checking the appropriate box:
- 🌟 Awesome comment, a human might have missed that.
- ✅ Helpful comment
- 🤷 Neutral
- ❌ This comment is not helpful
| ```bash | ||
| grep -rh "@bpm\.process\s*:" srv/external/*.cds 2>/dev/null | ||
| ls srv/workflows/ 2>/dev/null |
There was a problem hiding this comment.
Logic Error: The grep pattern is wrong for finding local process IDs. The annotation that carries the process definition ID is @bpm.process.start, @bpm.process.cancel, etc. — not a bare @bpm.process:. The pattern @bpm\.process\s*: would not match any actual annotation and would always return empty results, causing Step 5's cross-reference to show every remote process as ⬇️ not imported.
Consider scanning for the id: field within the annotation blocks, or use a pattern that matches the actual generated content of the .cds files (e.g., the @bpm.process: annotation on the service itself):
grep -rh "bpm\.process" srv/external/*.cds 2>/dev/null
ls srv/workflows/*.json 2>/dev/null | xargs -I{} basename {} .jsonUsing the workflow JSON filenames from srv/workflows/ is the most reliable source of local process IDs.
| ```bash | |
| grep -rh "@bpm\.process\s*:" srv/external/*.cds 2>/dev/null | |
| ls srv/workflows/ 2>/dev/null | |
| ls srv/workflows/*.json 2>/dev/null | xargs -I{} basename {} .json |
Double-check suggestion before committing. Edit this comment for amendments.
Please provide feedback on the review comment by checking the appropriate box:
- 🌟 Awesome comment, a human might have missed that.
- ✅ Helpful comment
- 🤷 Neutral
- ❌ This comment is not helpful
1 participant
Summary
.claude/commands/cap-build-process.md— a Claude Code slash command available to anyone working in this repocds env get→.cdsrc-private.json→cf service-key), fetches a token, calls the SBPA API, and cross-references remote processes against locally imported onesTest plan
@cap-js/processinstalled/cap-build-processand verify the command loads