coulomb/activity-core
2
0
Fork 0
generated from coulomb/repo-seed
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Align activity-core scope boundaries

Browse Source
This commit is contained in:
Bernd Worsch
2026-06-18 15:11:48 +02:00
parent 78eed5f942
commit 977a3bd97f
7 changed files with 530 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
docs/adr/adr-003-rule-instruction-model.md
View File

@@ -216,11 +216,21 @@ it. The output schema must define `List[TaskSpec]` or a compatible envelope.
#### `review_required: true`
When set, the instruction's proposed task list is written to a **pending review
queue** in issue-core rather than directly created. A human or curator agent
reviews and approves/rejects before tasks are materialised. This is the default
for instructions that create high-impact tasks (cross-repo changes, security
responses, production operations).
When set today, the instruction's task/report output is marked with
`review_required=true` in activity-core audit metadata. For report-producing
instructions, this flag is also persisted in configured report sinks so an
operator can distinguish validated-but-review-worthy output from routine
output.
activity-core does **not** currently route proposed tasks to a pending review
queue. That queue must be owned by issue-core, because issue-core owns task
lifecycle state. Until issue-core exposes a review contract, `review_required`
is metadata only; it must not be treated as evidence that live task creation was
held for approval.
Future issue-core review integration may use the same field, but that change
must update the issue sink contract and tests before any ActivityDefinition
relies on queue routing.
#### Evaluation semantics
@@ -286,7 +296,8 @@ This boundary makes future extraction to `rules-core` a packaging exercise, not
tasks" behaviour is replaced by explicit rule blocks.
- A new `RuleEvaluator` class (AST walker) is added to `src/activity_core/rules/`.
- A new `InstructionExecutor` class handles prompt rendering, LLM call, output
validation, and review queue routing.
validation, and review-required audit metadata. Pending review queue routing
remains a future issue-core integration.
- Integration tests for rule evaluation use fixture JSON; no running Temporal required.
- The `task_spawn_log` table is added to the Postgres schema (new Alembic migration).
- ActivityDefinition files that omit both `rules` and `instructions` are valid

8
docs/conventions.md
View File

@@ -18,7 +18,7 @@ extension point `af654abb`).
| Queue name | Registered workers |
|---|---|
| `orchestrator-tq` | `RunActivityWorkflow` and all its activities (`load_activity_definition`, `resolve_context`, `log_run`) |
| `task-execution-tq` | `TaskExecutorWorkflow` and all concrete task type workflows |
| `task-execution-tq` | `TaskExecutorWorkflow` compatibility stub only; real execution belongs in per-repo workers |
**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
@@ -60,6 +60,12 @@ 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.
---
## Search attributes