e81357e1df
Agents ended turns with "I'll wait … I'll be notified" expecting a background-completion callback that this environment never delivers, so the turn hung and left the planning sentence stuck in the channel. Add a claude-platform rule that no such notification exists — finish within the turn (foreground/poll) or ask the user for a follow-up. Also suppress the elapsed-time suffix on progress messages until at least one 5s bucket has elapsed, so freshly-created progress no longer shows a meaningless "0초". Update the affected message-runtime expectations. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
37 lines
3.3 KiB
Markdown
37 lines
3.3 KiB
Markdown
# Platform Rules
|
|
|
|
You have a `send_message` tool that sends a message immediately while you are still working.
|
|
Use it to acknowledge a request before starting longer work.
|
|
|
|
When working as a sub-agent or teammate, only use `send_message` if the main agent explicitly asked you to.
|
|
|
|
## Background work never notifies you — finish within the turn
|
|
|
|
Nothing in this environment re-invokes you when a background process, a background shell command, or a `run_in_background` job finishes. You will NOT be automatically notified when a build, compile, download, deploy, or any background task completes. The built-in tool descriptions that say "you'll be notified when it finishes" do NOT apply here.
|
|
|
|
If you end your turn with a sentence like "I'll wait for the build to complete — I'll be notified", the turn simply ends and nothing ever resumes — the user is left stuck staring at that message. This is a real, repeated failure. Do not do it.
|
|
|
|
Therefore:
|
|
|
|
- Do not launch long work in the background and then end the turn expecting a callback. Run it in the foreground and block/poll until it actually finishes inside this same turn, then report the real result.
|
|
- If something genuinely cannot complete within one turn, do not pretend a notification is coming. Finish with a concrete status and explicitly ask the user to send a follow-up message to continue. For recurring polling of CI/scheduled work, use the `schedule_task` / `watch_ci` tools, which DO re-invoke you.
|
|
- Never leave an intermediate "I'll wait … I'll be notified" planning sentence as your final answer.
|
|
|
|
## Media attachments
|
|
|
|
When a locally generated image, screenshot, video, audio, or document should appear in Discord, include a `MEDIA:` directive on its own line with an absolute local path:
|
|
|
|
```text
|
|
MEDIA:/absolute/path/preview.mp4
|
|
```
|
|
|
|
`MEDIA:` lines are hidden from the visible message and uploaded as native Discord attachments. Use absolute local paths only, do not repeat the same path in the visible text, and do not use generic markdown links or plain file paths as attachment directives. Supported formats include PNG, JPEG, GIF, WebP, BMP, MP4, MOV, WebM, MP3, WAV, OGG, M4A, FLAC, PDF, ZIP, TXT, Markdown, CSV, and JSON. SVG is not accepted.
|
|
|
|
## Making channel registration live (never fake a restart)
|
|
|
|
You run INSIDE `ejclaw.service`, so a plain `systemctl --user restart ejclaw.service` from within your turn kills you mid-command and cannot be confirmed — never claim a restart/reload succeeded without evidence.
|
|
|
|
The canonical registration paths already make the change live for you: `bun setup/index.ts --step register …` and `bun scripts/deregister-room.ts …` both send `SIGHUP` to the running service's main PID after the DB write (via `signalEjclawReload()`), which triggers `runtimeState.reloadRoomBindings()`. So a registered/deregistered channel is picked up immediately with no full restart. Prefer these paths.
|
|
|
|
If you ever change room bindings by a raw DB write, reload manually with `kill -HUP "$(systemctl --user show -p MainPID --value ejclaw.service)"` (main PID only — your agent subprocess survives). Then VERIFY before reporting: confirm the `Room bindings reloaded` log or that `getRegisteredGroup(jid)` resolves. Only a genuine code/env change needs a full restart, which must use the detached `systemd-run … systemctl --user restart` form and be verified in a separate scheduled task.
|