Enforce bounded operation guardrails

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a028de-e2c8-7732-8521-46a7fc5db82f

docs/conventions.md

@@ -18,7 +18,6 @@ extension point `af654abb`).
 | Queue name | Registered workers |
 |---|---|
 | `orchestrator-tq` | `RunActivityWorkflow` and all its activities (`load_activity_definition`, `resolve_context`, `log_run`) |
-| `task-execution-tq` | Legacy `TaskExecutorWorkflow` stub only when `ACTIVITY_CORE_ENABLE_TASK_EXECUTOR_STUB=true`; real execution belongs in per-repo workers / agent-harness |
 
 **Rule:** a workflow and its activities must be registered on the same task queue.
 Cross-queue activity calls require an explicit `task_queue` argument on
@@ -32,7 +31,6 @@ See `docs/idempotency.md` for the full workflow ID strategy.
 
 Summary:
 - `RunActivityWorkflow`: `activity-{activity_id}:{trigger_key}`
-- `TaskExecutorWorkflow`: `task-{run_id}:{task_type}:{index}`
 - Temporal Schedules: `activity-schedule-{activity_id}`
 
 ---
@@ -56,15 +54,8 @@ Each worker process registers:
 - **Workflows**: `worker.register_workflow(WorkflowClass)`
 - **Activities**: `worker.register_activity(activity_function)`
 
-A single process may run workers for multiple task queues, but each `Worker`
-instance is bound to one task queue. Use separate `Worker` instances for
-`orchestrator-tq` and `task-execution-tq`.
-
-`TaskExecutorWorkflow` is not a production execution surface for activity-core.
-It exists only as a compatibility/idempotency stub that writes a synthetic
-`task_instances` row in older tests and dev flows. Do not add concrete task
-execution logic here; execution ownership belongs to per-repo workers or a
-future execution-owned repo/workplan.
+The activity-core process registers one `Worker` on `orchestrator-tq`. Execution
+ownership belongs to downstream consumers and approved execution services.
 
 ---