feat(daemon-subject): in-tree task + requirements adapters under animus subject

Adds in-process SubjectBackend adapters that mount the existing in-tree
task and requirements services under the unified `animus subject --kind
<kind>` surface alongside externally-installed subject_backend plugins.

In-tree adapters:
- InTreeTaskSubjectBackend registers under kind=task
- InTreeRequirementsSubjectBackend registers under kind=requirement
- Both wrap the existing TaskProvider / RequirementsProvider unchanged;
  only the wire-protocol surface moves. Both adapter loops speak the
  same JSON-RPC frame protocol the PluginHost already understands, run
  as tokio tasks over duplex pipes, and register with the SubjectRouter
  the same way external plugin processes do
- Wire id convention: task:TASK-NNNN / requirement:REQ-NNNN; the
  adapter strips/re-adds the kind prefix at the boundary so the in-tree
  services keep using bare IDs
- External plugins claiming the same kind displace the in-tree adapter
  (SubjectRouter rejects duplicates; we filter the in-tree side before
  router build so external wins cleanly with an operator-facing warning)
- ANIMUS_DAEMON_DISABLE_BUILTIN_TASK_ADAPTER=1 and
  ANIMUS_DAEMON_DISABLE_BUILTIN_REQUIREMENTS_ADAPTER=1 opt-out per adapter

New CLI verbs on the subject surface:
- animus subject next --kind <kind>       (highest-priority Ready)
- animus subject status --kind <kind> --id <id> --status <s>

Docs:
- docs/reference/cli/index.md adds the `subject` command tree
- docs/reference/mcp-tools.md notes the unified subject surface
- CLAUDE.md describes the in-tree adapter and the env opt-outs

Deferred to a follow-up commit (NOT in this commit, per scope-safety
call): wholesale deletion of the legacy `animus task`, `animus
requirements`, and `ao_task_*` / `ao_requirements_*` MCP tool surfaces.
The legacy CLI and MCP surfaces remain available alongside the subject
surface; both read and write the same `~/.animus/<repo-scope>/` state,
which was verified end-to-end against a temp project root (create via
subject CLI → list via legacy task CLI shows the same task; status set
via subject CLI → next via subject CLI returns the just-readied task).
The deferral keeps this commit minimal-risk: ~3000 LOC of CLI/MCP
deletions plus their cross-crate references warrant their own commit
with isolated verification.

Tests added (9 in this commit):
- subject_dispatch::in_tree_task_adapter_mounts_by_default
- subject_dispatch::disable_builtin_task_env_unmounts_only_task
- subject_dispatch::discovers_zero_subject_plugins_router_is_empty
  (updated to disable in-tree adapters so it observes the truly-empty
  case; in-tree adapters are now on-by-default)
- inproc_subject_backend::strip_and_add_kind_prefix_round_trip
- inproc_subject_backend::parse_priority_canonicalizes_aliases
- inproc_subject_backend::adapter_opts_default_enables_both
- inproc_subject_backend::disable_env_overrides_default
- inproc_subject_backend::force_disable_overrides_env

Test results: orchestrator-daemon-runtime 99/99 pass;
orchestrator-core 222/222 pass; orchestrator-cli 390/391 pass (1
pre-existing failure in ops_plugin TOFU test, unrelated). Smoke tests
verified against a temp project root for both kinds across all six
subject verbs (list/get/create/update/next/status).

Author: Shooksie

CLAUDE.md

@@ -148,14 +148,32 @@ Web UI:
 Visible top-level command groups currently include:
 
 - `daemon`, `agent`, `project`, `queue`, `task`, `workflow`
-- `vision`, `requirements`, `architecture`
+- `requirements`, `subject`
 - `history`, `errors`, `git`, `skill`, `model`, `runner`
-- `status`, `output`, `mcp`, `web`, `setup`, `tui`, `doctor`
-
-Hidden but implemented:
-
-- `review`
-- `qa`
+- `status`, `now`, `output`, `mcp`, `web`, `setup`, `init`, `doctor`
+- `pack`, `plugin`, `trigger`, `logs`, `cloud`
+
+Hidden but implemented: none currently.
+
+For tasks and requirements, the v0.4.0 cut adds in-tree
+`SubjectBackend` adapters under the unified `animus subject --kind
+<kind>` surface. The legacy `animus task` and `animus requirements`
+command trees still exist alongside the subject surface; both routes
+read and write the same `~/.animus/<repo-scope>/` state. Set
+`ANIMUS_DAEMON_DISABLE_BUILTIN_TASK_ADAPTER=1` or
+`ANIMUS_DAEMON_DISABLE_BUILTIN_REQUIREMENTS_ADAPTER=1` to opt out of
+either in-tree adapter. External subject_backend plugins claiming
+`kind=task` or `kind=requirement` automatically displace the in-tree
+adapter (the `SubjectRouter` rejects duplicate kinds at startup).
+
+Subject CLI verbs available against any registered backend:
+
+- `animus subject list --kind <kind>`
+- `animus subject get --kind <kind> --id <id>`
+- `animus subject create --kind <kind> --title <title> [...]`
+- `animus subject update --kind <kind> --id <id> [...]`
+- `animus subject next --kind <kind>`              (highest-priority Ready)
+- `animus subject status --kind <kind> --id <id> --status <s>`
 
 Use `cargo run -p orchestrator-cli -- --help` or `docs/reference/cli/index.md`
 when changing or documenting the command tree.
@@ -214,7 +232,8 @@ If GraphQL contracts change, verify the Rust schema export path and regenerate c
 
 Animus is meant to self-host its planning and execution state.
 
-Common flow:
+Common flow (legacy task surface; both `animus task` and `animus subject
+--kind task` operate on the same in-tree state):
 
 ```bash
 animus task next
@@ -224,5 +243,13 @@ animus queue list
 animus daemon health
 ```
 
+Equivalent via the unified subject surface:
+
+```bash
+animus subject next --kind task
+animus subject status --kind task --id task:TASK-XXX --status in-progress
+animus workflow run --task-id TASK-XXX
+```
+
 If a task is specifically about persistence or migrations, it can justify direct state-file work.
 Otherwise, treat Animus state as a command surface, not a manual editing target.

Cargo.lock

@@ -16,6 +16,14 @@ pub(crate) enum SubjectCommand {
     Create(SubjectCreateArgs),
     /// Update a subject through the active subject_backend plugin.
     Update(SubjectUpdateArgs),
+    /// Return the highest-priority Ready subject for the given kind.
+    ///
+    /// Backed by the in-tree task / requirement adapters; external
+    /// subject_backend plugins may opt in by implementing `<kind>/next`.
+    /// Returns JSON `null` when no eligible subject exists.
+    Next(SubjectNextArgs),
+    /// Set the status of a subject by id through the active subject_backend.
+    Status(SubjectStatusArgs),
 }
 
 #[derive(Debug, Args)]
@@ -90,3 +98,23 @@ pub(crate) struct SubjectUpdateArgs {
     #[arg(long, value_name = "L1,L2", value_delimiter = ',')]
     pub labels: Vec<String>,
 }
+
+#[derive(Debug, Args)]
+pub(crate) struct SubjectNextArgs {
+    /// Subject kind to route through.
+    #[arg(long, value_name = "KIND")]
+    pub kind: String,
+}
+
+#[derive(Debug, Args)]
+pub(crate) struct SubjectStatusArgs {
+    /// Subject kind to route through.
+    #[arg(long, value_name = "KIND")]
+    pub kind: String,
+    /// Backend-qualified subject id.
+    #[arg(long, value_name = "ID")]
+    pub id: String,
+    /// New normalized status to set.
+    #[arg(long, value_name = "STATUS")]
+    pub status: String,
+}

crates/orchestrator-cli/src/cli_types/subject_types.rs

@@ -5,7 +5,10 @@ use orchestrator_daemon_runtime::{resolve_subject_dispatch, SubjectPluginDispatc
 use serde::Serialize;
 use serde_json::{json, Value};
 
-use crate::{print_value, SubjectCommand, SubjectCreateArgs, SubjectGetArgs, SubjectListArgs, SubjectUpdateArgs};
+use crate::{
+    print_value, SubjectCommand, SubjectCreateArgs, SubjectGetArgs, SubjectListArgs, SubjectNextArgs,
+    SubjectStatusArgs, SubjectUpdateArgs,
+};
 
 #[derive(Debug, Serialize)]
 struct SubjectCallResponse {
@@ -22,6 +25,8 @@ pub(crate) async fn handle_subject(command: SubjectCommand, project_root: &str,
         SubjectCommand::Get(args) => handle_subject_get(args, project_root, json).await,
         SubjectCommand::Create(args) => handle_subject_create(args, project_root, json).await,
         SubjectCommand::Update(args) => handle_subject_update(args, project_root, json).await,
+        SubjectCommand::Next(args) => handle_subject_next(args, project_root, json).await,
+        SubjectCommand::Status(args) => handle_subject_status(args, project_root, json).await,
     }
 }
 
@@ -96,6 +101,25 @@ async fn handle_subject_update(args: SubjectUpdateArgs, project_root: &str, json
     dispatch(kind, "update", params, project_root, json).await
 }
 
+async fn handle_subject_next(args: SubjectNextArgs, project_root: &str, json: bool) -> Result<()> {
+    let kind = require_kind(&args.kind)?;
+    dispatch(kind, "next", None, project_root, json).await
+}
+
+async fn handle_subject_status(args: SubjectStatusArgs, project_root: &str, json: bool) -> Result<()> {
+    let kind = require_kind(&args.kind)?;
+    let id = args.id.trim();
+    if id.is_empty() {
+        return Err(anyhow!("--id must not be empty"));
+    }
+    let status = args.status.trim();
+    if status.is_empty() {
+        return Err(anyhow!("--status must not be empty"));
+    }
+    let params = Some(json!({ "id": id, "status": status }));
+    dispatch(kind, "status", params, project_root, json).await
+}
+
 fn require_kind(raw: &str) -> Result<&str> {
     let trimmed = raw.trim();
     if trimmed.is_empty() {

crates/orchestrator-cli/src/services/operations/ops_subject.rs

@@ -17,6 +17,7 @@ glob = "0.3"
 orchestrator-core = { workspace = true }
 orchestrator-logging = { workspace = true }
 orchestrator-plugin-host = { workspace = true }
+orchestrator-providers = { workspace = true }
 animus-plugin-protocol = { workspace = true }
 protocol = { workspace = true }
 serde = { version = "1.0", features = ["derive"] }