Structured commands and thread-to-job binding

coilyco-ops commented

2026-08-12 11:11:51 +00:00

Member

Outcome

A dev action is invoked as a named command with a schema, and a Discord thread is bound to the job it is about, so follow-ups target that run.

Why

Free-text is the right interface for conversation and the wrong one for consequential actions. "Deploy the thing" and "deploy the other thing" are one paraphrase apart, and a natural-language turn gives the harness no structural way to tell them apart before acting.

Thread binding is the other half. Once work is durable, a follow-up like "cancel that" or "what is it doing" needs a referent, and the thread is the natural one.

Scope

Item 15 - structured commands.

Discord application commands with declared parameter schemas for job-submitting actions.
Schemas are the authority on arguments; a command is not a paraphrase of a sentence.
Natural-language conversation continues to work unchanged. This adds a structured path, it does not replace the conversational one.
Registering application commands requires the applications.commands scope on Deep's Discord application. Deployment-side notes tracked in coilyco-bridge/deploy.

Item 16 - thread-as-work-context.

A submitted job binds to a thread at its origin.
Follow-up turns in that thread resolve to that job without the requester repeating an id.
The binding is explicit and inspectable, not inferred from recent history.

A note on argument bounding

Two issues in the deploy repository - coilyco-bridge/deploy#358 and coilyco-bridge/deploy#359 - both failed for the same reason: the surrounding tooling bounds tool names but not tool arguments.

That is worth remembering here, because structured commands are the first place this harness would own an argument schema itself rather than inherit one. Whatever bounds a command's parameters is a real authority boundary, and it should be treated as one rather than as input validation.

Acceptance

A job-submitting action is invocable as a schema-declared command.
A follow-up in a bound thread resolves to the right job with no id repeated.
Conversational turns still work.

Depends on

#143 - commands submit jobs and threads bind to jobs, so jobs come first.

Next owner

Engineer.

## Outcome A dev action is invoked as a named command with a schema, and a Discord thread is bound to the job it is about, so follow-ups target that run. ## Why Free-text is the right interface for conversation and the wrong one for consequential actions. "Deploy the thing" and "deploy the other thing" are one paraphrase apart, and a natural-language turn gives the harness no structural way to tell them apart before acting. Thread binding is the other half. Once work is durable, a follow-up like "cancel that" or "what is it doing" needs a referent, and the thread is the natural one. ## Scope **Item 15 - structured commands.** * Discord application commands with declared parameter schemas for job-submitting actions. * Schemas are the authority on arguments; a command is not a paraphrase of a sentence. * Natural-language conversation continues to work unchanged. This adds a structured path, it does not replace the conversational one. * Registering application commands requires the `applications.commands` scope on Deep's Discord application. Deployment-side notes tracked in `coilyco-bridge/deploy`. **Item 16 - thread-as-work-context.** * A submitted job binds to a thread at its origin. * Follow-up turns in that thread resolve to that job without the requester repeating an id. * The binding is explicit and inspectable, not inferred from recent history. ## A note on argument bounding Two issues in the deploy repository - https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/358 and https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/359 - both failed for the same reason: the surrounding tooling bounds tool *names* but not tool *arguments*. That is worth remembering here, because structured commands are the first place this harness would own an argument schema itself rather than inherit one. Whatever bounds a command's parameters is a real authority boundary, and it should be treated as one rather than as input validation. ## Acceptance * A job-submitting action is invocable as a schema-declared command. * A follow-up in a bound thread resolves to the right job with no id repeated. * Conversational turns still work. ## Depends on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/143 - commands submit jobs and threads bind to jobs, so jobs come first. ## Next owner Engineer.

coilyco-ops referenced this issue

2026-08-12 11:12:55 +00:00

Job record: make a unit of work first-class, durable, and idempotent #143

coilyco-ops referenced this issue

2026-08-12 11:55:12 +00:00

Expose MCP prompts as Discord slash commands, which adds a summon path the access policy does not model #127

coilyco-ops referenced this issue

2026-08-12 11:56:36 +00:00

Async job lifecycle: submit, poll, notify, cancel #144

coilyco-ops referenced this issue

2026-08-12 11:56:47 +00:00

Job-scoped telemetry and progress reporting #146

coilyco-ops commented

2026-08-12 11:56:57 +00:00

Author

Member

This unit splits in half, and the halves have different timelines

Direction from Kai, 2026-08-12 session. Batch-wide decisions are recorded on the entry point, #143.

The structured-command half is blocked on a token decision

This issue notes it in passing:

Registering application commands requires the applications.commands scope on Deep's Discord application.

That scope widening was decided separately on #127 and the answer is not yet — deferred past August 19. Echo's Discord surface is read-and-reply today, and widening what its token can do in the week before a permanent public livestream is not a trade worth making.

#127 and this issue need the same scope for the same reason, so it is one decision covering both, deferred once. When #127 is revisited after August 19, item 15 here unblocks with it.

The thread-binding half is not blocked

Item 16 — thread-as-work-context — needs no new Discord scope. Binding a job to a thread at its origin and resolving follow-up turns in that thread to that job is ordinary message handling against a capability Echo already has.

So this unit proceeds on item 16 as soon as #143 lands, in parallel with #144 and #146, and item 15 waits on the #127 revisit. Do not treat the whole issue as blocked.

Both halves' acceptance criteria survive the split cleanly. "A follow-up in a bound thread resolves to the right job with no id repeated" and "conversational turns still work" are both testable without a single application command existing.

Timing

The demo track owns the week to August 19. The batch starts August 20 and is the priority from then on.

The note on argument bounding stands, and gains weight

This issue's observation is worth restating now that item 15 has slipped:

Structured commands are the first place this harness would own an argument schema itself rather than inherit one. Whatever bounds a command's parameters is a real authority boundary, and it should be treated as one rather than as input validation.

Two coilyco-bridge/deploy issues (358, 359) failed because the surrounding tooling bounds tool names but not tool arguments. That reasoning now lands in a window where per-requester authority and attribution are also in scope — Kai un-deferred items 5 and 6 in the same session, see #143 and #145. When item 15 is picked up, the argument schema and the authority model should be designed against each other rather than sequentially.

## This unit splits in half, and the halves have different timelines Direction from Kai, 2026-08-12 session. Batch-wide decisions are recorded on the entry point, #143. ## The structured-command half is blocked on a token decision This issue notes it in passing: > Registering application commands requires the `applications.commands` scope on Deep's Discord application. **That scope widening was decided separately on #127 and the answer is not yet — deferred past August 19.** Echo's Discord surface is read-and-reply today, and widening what its token can do in the week before a permanent public livestream is not a trade worth making. #127 and this issue need the same scope for the same reason, so it is one decision covering both, deferred once. When #127 is revisited after August 19, item 15 here unblocks with it. ## The thread-binding half is not blocked Item 16 — thread-as-work-context — needs no new Discord scope. Binding a job to a thread at its origin and resolving follow-up turns in that thread to that job is ordinary message handling against a capability Echo already has. **So this unit proceeds on item 16 as soon as #143 lands, in parallel with #144 and #146, and item 15 waits on the #127 revisit.** Do not treat the whole issue as blocked. Both halves' acceptance criteria survive the split cleanly. "A follow-up in a bound thread resolves to the right job with no id repeated" and "conversational turns still work" are both testable without a single application command existing. ## Timing The demo track owns the week to August 19. The batch starts August 20 and is the priority from then on. ## The note on argument bounding stands, and gains weight This issue's observation is worth restating now that item 15 has slipped: > Structured commands are the first place this harness would own an argument schema itself rather than inherit one. Whatever bounds a command's parameters is a real authority boundary, and it should be treated as one rather than as input validation. Two `coilyco-bridge/deploy` issues (358, 359) failed because the surrounding tooling bounds tool *names* but not tool *arguments*. That reasoning now lands in a window where per-requester authority and attribution are also in scope — Kai un-deferred items 5 and 6 in the same session, see #143 and #145. When item 15 is picked up, the argument schema and the authority model should be designed against each other rather than sequentially.

coilyco-ops referenced this issue

2026-08-12 11:58:51 +00:00

Job record: make a unit of work first-class, durable, and idempotent #143

coilyco-ops referenced this issue

2026-08-12 12:03:44 +00:00

Per-requester authority: a job acts as the principal who asked for it #150

coilyco-ops referenced this issue from a commit

2026-08-12 12:13:40 +00:00

feat(jobs): make telemetry addressable by unit of work

coilyco-ops referenced this issue from a commit

2026-08-12 12:18:49 +00:00

feat(commands): declare job actions with a schema, and bind a thread to its job