Map Kimaki thread attribution into generic Homeboy notification context

[chubes4]

Ownership

wp-coding-agents explicitly owns the integration knowledge between Kimaki, OpenCode, runtime signatures, and installed orchestration components. Kimaki remains Homeboy-agnostic; Homeboy remains Kimaki-agnostic.

Depends on generic upstream Kimaki attribution issue: remorses/kimaki#137

Goal

When a Kimaki-originated OpenCode tool invocation runs Homeboy, map the invocation's stable thread/channel attribution into Homeboy's generic caller context:

• HOMEBOY_NOTIFICATION_TRANSPORT=discord.run-completion
• HOMEBOY_NOTIFICATION_ROUTE=discord:v1:thread: (or channel form)

Contract

• Implement in the managed Kimaki/OpenCode bridge integration owned here, not in Kimaki or Homeboy core.
• Consume only documented KIMAKI_* attribution supplied per tool/session by upstream dm-context-filter: live prompt still exposes Kimaki spawn guidance and noisy --user examples #137.
• Mapping must be invocation-scoped and concurrency-safe; never mutate process-global state shared by sessions.
• Do not pass bot credentials or any secret in the route.
• Register/update runtime signatures consistently so DMC worktree attribution and Homeboy notification attribution derive from the same bridge context.
• Install/upgrade must sync the adapter idempotently and managed-plugin rig must verify it survives Kimaki updates.
• Two concurrent synthetic Kimaki thread invocations must produce distinct Homeboy routes with no cross-delivery.
• If upstream attribution is absent, omit Homeboy notification context; never guess or use a global thread fallback.
• No legacy aliases or static-thread compatibility.

Route cleanup

Discord delivery only needs the destination channel/thread snowflake. Keep the integration route minimal; do not carry unused guild IDs.

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode with Claude Opus 4.5
• Used for: Identified the correct integration owner and specified concurrency-safe context mapping