Allow command to be optional if deps are present

[leynos]

Problem

An aggregate action that exists only to order or group dependencies must still
provide a no-op command today. For example, Catnap uses command: ":" solely
to make its sequential all action valid:

actions:
  - name: all
    description: Run comprehensive checks sequentially
    command: ":"
    deps:
      - check-fmt
      - lint
      - test
      - spelling
    dependency_order: serial

https://github.com/leynos/catnap/blob/de453cb63aa030844ef08e1c60d4981b6d25d949/Netsukefile#L3-L12

The : recipe is not part of the workflow’s intent: the dependencies are the
entire action. Requiring it adds implementation noise to otherwise declarative
manifests.

Requirement

Allow command to be omitted when an action or target has at least one
dependency. Netsuke should model it as a dependency-only node with no recipe
of its own.

Acceptance criteria

• An action or target with non-empty deps may omit command.
• A manifest entry with neither command nor deps remains invalid.
• Dependency ordering, deduplication, and failure behaviour remain unchanged,
  including dependency_order: serial.
• Generated Ninja output represents the dependency-only node without a
  synthetic shell no-op.
• Add manifest, graph-generation, and CLI regression coverage.

[leynos]

@CodeRabbit plan

[coderabbitai]

Coding Plan

Summary

• Relax the AST so a Target deserializes with recipe: Option<Recipe>, keeping recipe exclusivity, empty-command, and Rule recipe validation intact.
• Move the "recipe or deps required" invariant to a post-render manifest validation pass with a new localised diagnostic.
• Represent the dependency-only node as a BuildEdge with action_id: None, leaving ordering, deduplication, and cycle detection unchanged.
• Render an action-less edge as a built-in Ninja phony build statement in both the plain and dyndep-bundle paths, and add manifest, graph-generation, and CLI regression coverage.

Design Choices

Design Choice 1: Where must the "recipe or deps required" invariant be enforced?

Options Considered:

1. Add a custom Deserialize impl on Target (a RawTarget helper) that inspects raw recipe fields and deps together at parse time.
2. Relax the AST to accept an absent recipe (Option), then add a post-render validation pass in the manifest layer that checks recipe presence against rendered deps.

Chosen Option: 2

Rationale: The manifest post-render pass sees fully rendered deps values and follows the existing precedent of register_manifest_vars, while the AST change stays minimal and keeps Rule recipe validation strict.

Design Choice 2: How must a recipe-less edge be represented in the IR?

Options Considered:

1. Change BuildEdge.action_id to Option.
2. Register a reserved zero-command Action and reuse the existing code path unchanged.
3. Introduce a dedicated ActionId newtype wrapping an Option.

Chosen Option: 1

Rationale: Option states the "no action" case directly, matches the ticket's dependency-only model, and avoids emitting a synthetic recipe that Option 2 would create.

Design Choice 3: Which dependency fields satisfy "has at least one dependency"?

Options Considered:

1. Count only deps (implicit dependencies).
2. Count deps, sources, and order_only_deps.

Chosen Option: 1

Rationale: The acceptance criteria name deps specifically, and a node whose only reason to exist is grouping or ordering uses deps.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Make the recipe optional in the AST

Relax the parser so a Target can deserialize with no recipe fields, while keeping recipe exclusivity and empty-command validation intact and leaving Rule recipe requirements strict.

Allow a Target to carry no recipe

Represent an absent recipe as None instead of a parse error.

• Change Target.recipe in src/ast/target.rs from Recipe to Option<Recipe>.
• Factor the recipe tuple-matching logic in src/ast/mod.rs into a shared builder (for example Recipe::from_parts(command, script, rule)) that returns Ok(None) when all three fields are absent, preserves the "mutually exclusive" error when more than one is present, and preserves the empty-command (EMPTY_COMMAND_LIST_ERROR) check.
• Keep Recipe's own Deserialize impl strict: it must still reject the all-absent case, so Rule (which flattens Recipe) continues to require a recipe.
• Give Target a custom Deserialize impl backed by a RawTarget helper (mirroring the RawRecipe precedent) that captures raw command/script/rule plus the remaining Target fields, calls the shared builder, and stores Option<Recipe>. Retain deny_unknown_fields behaviour.
• Confirm deserialize_actions in src/ast/mod.rs still forces phony = true on the mutated Target values.

🤖 Prompt for AI agents

Implement Phase 1: relax the AST parser so a Target can be built with no recipe,
while keeping recipe exclusivity and validation rules unchanged.

- In `src/ast/target.rs`, change the type of `Target.recipe` from `Recipe` to
`Option<Recipe>`.
- In `src/ast/mod.rs`, extract the existing recipe tuple-matching logic into a
shared builder function, for example `Recipe::from_parts(command, script,
rule)`. This builder must return `Ok(None)` when `command`, `script`, and `rule`
are all absent. It must keep returning the "mutually exclusive" error when more
than one of the three fields is present. It must keep the empty-command check
that uses `EMPTY_COMMAND_LIST_ERROR`.
- Keep the existing `Recipe` `Deserialize` implementation strict: it must still
reject the all-absent case. This keeps `Rule` (which flattens `Recipe`)
requiring a recipe.
- Add a custom `Deserialize` implementation for `Target`, backed by a
`RawTarget` helper struct, mirroring the existing `RawRecipe` precedent.
`RawTarget` must capture the raw `command`, `script`, and `rule` fields plus the
remaining `Target` fields. The `Deserialize` implementation must call the shared
builder and store the result as `Option<Recipe>` on `Target`. Retain the
`deny_unknown_fields` behaviour.
- Confirm that `deserialize_actions` in `src/ast/mod.rs` still forces `phony =
true` on the mutated `Target` values after this change.

Phase 2: Validate "recipe or deps required" in the manifest layer

Add a post-render validation pass so an entry with neither a recipe nor deps fails with a localised, manifest-level diagnostic, and add the new message key to every locale catalogue.

Task 1: Add the cross-field validation pass

Reject a recipe-less entry that also has empty deps.

• In src/manifest/mod.rs, after render_manifest returns in from_str_named, add a validation function (analogous to register_manifest_vars) that iterates manifest.actions chained with manifest.targets.
• For each entry, if recipe is None and deps.is_empty_content() is true, produce a ManifestError::Parse via manifest_structure_error/map_data_error, using the target name as the target argument.
• Use StringOrList::is_empty_content() for the deps check. Note the known quirk: an explicit empty-string scalar is not treated as empty; document this in the function comment.

Task 2: Register the new localisation key across all catalogues

Follow the all-locales-at-once process required by the build-time l10n audit.

• Declare a new key in src/localization/keys.rs, for example MANIFEST_TARGET_RECIPE_OR_DEPS_REQUIRED => "manifest.target.recipe_or_deps_required".
• Add a translated message with a { $target } placeable to locales/en-US/messages.ftl first, then to locales/en-GB/messages.ftl and every other locales/<tag>/messages.ftl catalogue. Match the tone of ir.empty_rule.
• Reference the key at the Task 2.1 call site via localization::message(keys::MANIFEST_TARGET_RECIPE_OR_DEPS_REQUIRED).with_arg("target", …).
• Run cargo build to trigger build_l10n_audit and confirm no missing/orphaned key findings.

🤖 Prompt for AI agents

Implement Phase 2: add a post-render manifest validation pass that rejects an
entry with neither a recipe nor `deps`, and add the required localisation key to
every locale catalogue.

- In `src/manifest/mod.rs`, after `render_manifest` returns inside
`from_str_named`, add a validation function analogous to
`register_manifest_vars`. This function must iterate `manifest.actions` chained
with `manifest.targets`.
- For each entry, if `recipe` is `None` and `deps.is_empty_content()` is `true`,
produce a `ManifestError::Parse` via
`manifest_structure_error`/`map_data_error`, passing the target name as the
`target` argument.
- Use `StringOrList::is_empty_content()` to check `deps`. Document in the
function comment the known quirk that an explicit empty-string scalar is not
treated as empty.
- In `src/localization/keys.rs`, declare a new key, for example
`MANIFEST_TARGET_RECIPE_OR_DEPS_REQUIRED =>
"manifest.target.recipe_or_deps_required"`.
- Add a translated message with a `{ $target }` placeable to
`locales/en-US/messages.ftl` first, then to `locales/en-GB/messages.ftl` and
every other `locales/<tag>/messages.ftl` catalogue. Match the tone of the
existing `ir.empty_rule` message.
- At the validation call site, reference the key via
`localization::message(keys::MANIFEST_TARGET_RECIPE_OR_DEPS_REQUIRED).with_arg("target",
…)`.
- Run `cargo build` to trigger `build_l10n_audit` and confirm it reports no
missing or orphaned key findings.

Phase 3: Lower a dependency-only node in the IR

Represent an edge with no action, and skip action registration when the recipe is absent. Keep dependency ordering, deduplication, and cycle detection unchanged.

Make BuildEdge.action_id optional

Model the "no action" state directly.

• Change BuildEdge.action_id in src/ir/graph.rs from String to Option<String>.
• In src/ir/from_manifest.rs process_targets, add a branch on Option<Recipe>: when the recipe is None, skip register_action and set action_id: None; otherwise keep the existing Recipe::Rule/Command/Script handling and set action_id: Some(id).
• Leave implicit_deps, dependency_order, order_only_deps, phony, and always lowering unchanged so serial ordering and deduplication behaviour do not change.
• Confirm src/ir/cycle.rs needs no change (it reads only inputs/implicit_deps).

🤖 Prompt for AI agents

Implement Phase 3: make `BuildEdge.action_id` optional in the IR, and skip
action registration for a recipe-less entry.

- In `src/ir/graph.rs`, change `BuildEdge.action_id` from type `String` to
`Option<String>`.
- In `src/ir/from_manifest.rs`, inside `process_targets`, add a branch on the
entry's `Option<Recipe>`. When the recipe is `None`, skip the call to
`register_action` and set `action_id: None`. When the recipe is present, keep
the existing `Recipe::Rule`/`Command`/`Script` handling unchanged and set
`action_id: Some(id)`.
- Leave the lowering of `implicit_deps`, `dependency_order`, `order_only_deps`,
`phony`, and `always` unchanged, so serial ordering and deduplication behaviour
do not change.
- Confirm that `src/ir/cycle.rs` needs no change, because it reads only `inputs`
and `implicit_deps`.

Phase 4: Emit a phony build statement for action-less edges

Render a dependency-only edge as a built-in phony build statement in both the plain and the dyndep-bundle generation paths, and keep graph-view projection working.

Task 1: Render action-less edges in Ninja

Substitute the literal phony rule token for a missing action_id.

• In src/ninja_gen/mod.rs generate_into, when edge.action_id is None, skip the graph.actions.get(...) lookup and do not raise MissingAction; pass action_restat: false to DisplayEdge.
• In DisplayEdge::fmt, write the rule segment as the resolved action_id when present, or the literal token phony when action_id is None. Keep the existing inputs/implicit_deps/order_only_deps rendering and escaping unchanged.
• Confirm the NamedAction rule-emission loop over graph.actions and validate_action_recipe need no change, because a dependency-only node registers no Action.

Task 2: Handle action-less edges in the dyndep path

Keep serial gating working for a recipe-less serial node (the Catnap case).

• In src/ninja_gen/dyndep.rs render_edge/generate_bundle_inner, skip the per-edge graph.actions.get(&edge.action_id) MissingAction lookup when action_id is None, mirroring Task 4.1.
• Confirm the serial gate/sidecar machinery (render_serial_block, SerialStages, .netsuke/serial reservation) is already generic over implicit_deps and needs no change; the terminal edge for the node must render through the updated DisplayEdge as build <name>: phony <gate-chain>.

Task 3: Keep graph-view projection tolerant of a missing action

Preserve dot/HTML rendering for a dependency-only node.

• In src/graph_view/mod.rs register_outputs, update the description lookup to handle edge.action_id: Option<String> (for example edge.action_id.as_ref().and_then(|id| graph.actions.get(id))), degrading to None description when absent.
• Adjust NodeMetadata.action_id handling to carry the Option through. The DOT/HTML renderers need no change because they consume GraphView only.

🤖 Prompt for AI agents

Implement Phase 4: render an action-less `BuildEdge` as a built-in `phony` Ninja
build statement in both the plain and dyndep-bundle generation paths, and keep
graph-view projection tolerant of a missing action.

- In `src/ninja_gen/mod.rs`, inside `generate_into`, when `edge.action_id` is
`None`, skip the `graph.actions.get(...)` lookup and do not raise
`MissingAction`. Pass `action_restat: false` to `DisplayEdge` in this case.
- In `DisplayEdge::fmt`, write the rule segment as the resolved `action_id` when
it is present, or the literal token `phony` when `action_id` is `None`. Keep the
existing rendering and escaping of `inputs`, `implicit_deps`, and
`order_only_deps` unchanged.
- Confirm that the `NamedAction` rule-emission loop over `graph.actions` and
`validate_action_recipe` need no change, because a dependency-only node
registers no `Action`.
- In `src/ninja_gen/dyndep.rs`, inside `render_edge`/`generate_bundle_inner`,
skip the per-edge `graph.actions.get(&edge.action_id)` lookup and the associated
`MissingAction` check when `action_id` is `None`, mirroring the plain-path
change.
- Confirm that the serial gate/sidecar machinery (`render_serial_block`,
`SerialStages`, `.netsuke/serial` reservation) already works generically over
`implicit_deps` and needs no change. The terminal edge for a recipe-less serial
node must render through the updated `DisplayEdge` as `build <name>: phony
<gate-chain>`.
- In `src/graph_view/mod.rs`, inside `register_outputs`, update the description
lookup to handle `edge.action_id` as `Option<String>` (for example,
`edge.action_id.as_ref().and_then(|id| graph.actions.get(id))`), degrading to a
`None` description when the action is absent.
- Adjust `NodeMetadata.action_id` handling to carry the `Option` through. Do not
change the DOT/HTML renderers, because they consume `GraphView` only.

Phase 5: Add regression coverage

Add fixtures and tests at the manifest, graph-generation, and CLI levels, plus BDD scenarios, per the acceptance criteria.

Task 1: Add manifest fixtures and AST/manifest tests

Cover both the valid dependency-only case and the still-invalid empty case.

• Add a valid fixture, tests/data/deps_only_action.yml, with an action that has deps (including a dependency_order: serial variant to mirror the Catnap example) and no command.
• Add or reuse a target variant, tests/data/deps_only_target.yml, for a targets: entry with deps and no recipe.
• Add positive parse tests (in tests/ast_tests/) asserting the entry parses and recipe is None.
• Confirm tests/data/missing_recipe.yml and tests/data/action_invalid.yml still fail (now via the Task 2.1 manifest-layer error). Keep the is_err() assertions in tests/ast_tests/manifest_files.rs.

Task 2: Add IR and Ninja generation tests

Assert the dependency-only node lowers and renders correctly.

• Add an ir_from_manifest test (following tests/ir_from_manifest_tests.rs patterns) asserting the dependency-only edge has action_id: None, its implicit_deps preserve manifest order, and the graph registers no extra Action.
• Add a ninja_gen test (following tests/ninja_gen_unit_tests.rs #[case] style) asserting the generated text contains build <name>: phony <deps> and contains no synthetic command = line for that node.
• Add a serial-case assertion (following tests/ninja_gen_integration_tests.rs/serial_dependency_* patterns) confirming a recipe-less serial node still produces the gate/sidecar chain and a terminal build <name>: phony <gate-chain> statement.

Task 3: Add BDD and CLI regression scenarios

Cover the end-to-end path per the acceptance criteria.

• Add a scenario to tests/features/manifest.feature that parses the dependency-only fixture successfully, mirroring the positive-shape scenarios.
• Add a scenario to tests/features/ninja.feature (mirroring "Target and action deps become implicit Ninja dependencies") asserting the build <name>: phony … line is present.
• Add a negative "does not contain" Then-step in tests/bdd/steps/ninja.rs (reusing get_ninja_content/assert_optional_contains) and use it to assert no synthetic command = line is emitted.
• Add a CLI round-trip test in tests/runner_tests.rs (following run_generate_subcommand_writes_file) confirming run succeeds and the generated file contains the phony build statement for the dependency-only node.

🤖 Prompt for AI agents

Implement Phase 5: add regression coverage for the dependency-only node feature
at the manifest, IR, Ninja-generation, BDD, and CLI levels.

- Add a valid fixture, `tests/data/deps_only_action.yml`, containing an action
with `deps` (including a `dependency_order: serial` variant to mirror the Catnap
example) and no `command`.
- Add or reuse a target variant, `tests/data/deps_only_target.yml`, for a
`targets:` entry with `deps` and no recipe.
- Add positive parse tests in `tests/ast_tests/` asserting the entry parses
successfully and `recipe` is `None`.
- Confirm `tests/data/missing_recipe.yml` and `tests/data/action_invalid.yml`
still fail parsing, now via the Task 2.1 manifest-layer error. Keep the existing
`is_err()` assertions in `tests/ast_tests/manifest_files.rs`.
- Add an `ir_from_manifest` test, following the patterns in
`tests/ir_from_manifest_tests.rs`, asserting the dependency-only edge has
`action_id: None`, that its `implicit_deps` preserve manifest order, and that
the graph registers no extra `Action`.
- Add a `ninja_gen` test, following the `#[case]` style in
`tests/ninja_gen_unit_tests.rs`, asserting the generated text contains `build
<name>: phony <deps>` and contains no synthetic `command =` line for that node.
- Add a serial-case assertion, following the patterns in
`tests/ninja_gen_integration_tests.rs` and `serial_dependency_*`, confirming a
recipe-less serial node still produces the gate/sidecar chain and a terminal
`build <name>: phony <gate-chain>` statement.
- Add a scenario to `tests/features/manifest.feature` that parses the
dependency-only fixture successfully, mirroring the existing positive-shape
scenarios.
- Add a scenario to `tests/features/ninja.feature`, mirroring "Target and action
deps become implicit Ninja dependencies", asserting the `build <name>: phony …`
line is present.
- Add a negative "does not contain" Then-step in `tests/bdd/steps/ninja.rs`,
reusing `get_ninja_content`/`assert_optional_contains`, and use it to assert
that no synthetic `command =` line is emitted.
- Add a CLI round-trip test in `tests/runner_tests.rs`, following
`run_generate_subcommand_writes_file`, confirming `run` succeeds and the
generated file contains the `phony` build statement for the dependency-only
node.

Research

Netsuke parses a YAML manifest into typed AST structures (src/ast/), lowers them to an intermediate build graph (src/ir/), then renders that graph into Ninja text (src/ninja_gen/).

The Target struct is shared by both targets: and actions: entries. Its recipe is a required #[serde(flatten)] Recipe enum. The enum's custom Deserialize impl enforces "exactly one of command/script/rule".

IR lowering (process_targets) always registers an Action and stores its hash in BuildEdge.action_id (a required String). Ninja generation looks up every edge's action and raises NinjaGenError::MissingAction if absent.

Serial ordering is handled downstream in src/ninja_gen/dyndep.rs, which already emits literal build …: phony … gate and sidecar statements.

Localisation keys are declared centrally in src/localization/keys.rs and audited at build time against all 35 locale catalogues.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement Phase 1: relax the AST parser so a Target can be built with no recipe,
while keeping recipe exclusivity and validation rules unchanged.

- In `src/ast/target.rs`, change the type of `Target.recipe` from `Recipe` to
`Option<Recipe>`.
- In `src/ast/mod.rs`, extract the existing recipe tuple-matching logic into a
shared builder function, for example `Recipe::from_parts(command, script,
rule)`. This builder must return `Ok(None)` when `command`, `script`, and `rule`
are all absent. It must keep returning the "mutually exclusive" error when more
than one of the three fields is present. It must keep the empty-command check
that uses `EMPTY_COMMAND_LIST_ERROR`.
- Keep the existing `Recipe` `Deserialize` implementation strict: it must still
reject the all-absent case. This keeps `Rule` (which flattens `Recipe`)
requiring a recipe.
- Add a custom `Deserialize` implementation for `Target`, backed by a
`RawTarget` helper struct, mirroring the existing `RawRecipe` precedent.
`RawTarget` must capture the raw `command`, `script`, and `rule` fields plus the
remaining `Target` fields. The `Deserialize` implementation must call the shared
builder and store the result as `Option<Recipe>` on `Target`. Retain the
`deny_unknown_fields` behaviour.
- Confirm that `deserialize_actions` in `src/ast/mod.rs` still forces `phony =
true` on the mutated `Target` values after this change.
===============================================================================

Task: 2

Implement Phase 2: add a post-render manifest validation pass that rejects an
entry with neither a recipe nor `deps`, and add the required localisation key to
every locale catalogue.

- In `src/manifest/mod.rs`, after `render_manifest` returns inside
`from_str_named`, add a validation function analogous to
`register_manifest_vars`. This function must iterate `manifest.actions` chained
with `manifest.targets`.
- For each entry, if `recipe` is `None` and `deps.is_empty_content()` is `true`,
produce a `ManifestError::Parse` via
`manifest_structure_error`/`map_data_error`, passing the target name as the
`target` argument.
- Use `StringOrList::is_empty_content()` to check `deps`. Document in the
function comment the known quirk that an explicit empty-string scalar is not
treated as empty.
- In `src/localization/keys.rs`, declare a new key, for example
`MANIFEST_TARGET_RECIPE_OR_DEPS_REQUIRED =>
"manifest.target.recipe_or_deps_required"`.
- Add a translated message with a `{ $target }` placeable to
`locales/en-US/messages.ftl` first, then to `locales/en-GB/messages.ftl` and
every other `locales/<tag>/messages.ftl` catalogue. Match the tone of the
existing `ir.empty_rule` message.
- At the validation call site, reference the key via
`localization::message(keys::MANIFEST_TARGET_RECIPE_OR_DEPS_REQUIRED).with_arg("target",
…)`.
- Run `cargo build` to trigger `build_l10n_audit` and confirm it reports no
missing or orphaned key findings.
===============================================================================

Task: 3

Implement Phase 3: make `BuildEdge.action_id` optional in the IR, and skip
action registration for a recipe-less entry.

- In `src/ir/graph.rs`, change `BuildEdge.action_id` from type `String` to
`Option<String>`.
- In `src/ir/from_manifest.rs`, inside `process_targets`, add a branch on the
entry's `Option<Recipe>`. When the recipe is `None`, skip the call to
`register_action` and set `action_id: None`. When the recipe is present, keep
the existing `Recipe::Rule`/`Command`/`Script` handling unchanged and set
`action_id: Some(id)`.
- Leave the lowering of `implicit_deps`, `dependency_order`, `order_only_deps`,
`phony`, and `always` unchanged, so serial ordering and deduplication behaviour
do not change.
- Confirm that `src/ir/cycle.rs` needs no change, because it reads only `inputs`
and `implicit_deps`.
===============================================================================

Task: 4

Implement Phase 4: render an action-less `BuildEdge` as a built-in `phony` Ninja
build statement in both the plain and dyndep-bundle generation paths, and keep
graph-view projection tolerant of a missing action.

- In `src/ninja_gen/mod.rs`, inside `generate_into`, when `edge.action_id` is
`None`, skip the `graph.actions.get(...)` lookup and do not raise
`MissingAction`. Pass `action_restat: false` to `DisplayEdge` in this case.
- In `DisplayEdge::fmt`, write the rule segment as the resolved `action_id` when
it is present, or the literal token `phony` when `action_id` is `None`. Keep the
existing rendering and escaping of `inputs`, `implicit_deps`, and
`order_only_deps` unchanged.
- Confirm that the `NamedAction` rule-emission loop over `graph.actions` and
`validate_action_recipe` need no change, because a dependency-only node
registers no `Action`.
- In `src/ninja_gen/dyndep.rs`, inside `render_edge`/`generate_bundle_inner`,
skip the per-edge `graph.actions.get(&edge.action_id)` lookup and the associated
`MissingAction` check when `action_id` is `None`, mirroring the plain-path
change.
- Confirm that the serial gate/sidecar machinery (`render_serial_block`,
`SerialStages`, `.netsuke/serial` reservation) already works generically over
`implicit_deps` and needs no change. The terminal edge for a recipe-less serial
node must render through the updated `DisplayEdge` as `build <name>: phony
<gate-chain>`.
- In `src/graph_view/mod.rs`, inside `register_outputs`, update the description
lookup to handle `edge.action_id` as `Option<String>` (for example,
`edge.action_id.as_ref().and_then(|id| graph.actions.get(id))`), degrading to a
`None` description when the action is absent.
- Adjust `NodeMetadata.action_id` handling to carry the `Option` through. Do not
change the DOT/HTML renderers, because they consume `GraphView` only.
===============================================================================

Task: 5

Implement Phase 5: add regression coverage for the dependency-only node feature
at the manifest, IR, Ninja-generation, BDD, and CLI levels.

- Add a valid fixture, `tests/data/deps_only_action.yml`, containing an action
with `deps` (including a `dependency_order: serial` variant to mirror the Catnap
example) and no `command`.
- Add or reuse a target variant, `tests/data/deps_only_target.yml`, for a
`targets:` entry with `deps` and no recipe.
- Add positive parse tests in `tests/ast_tests/` asserting the entry parses
successfully and `recipe` is `None`.
- Confirm `tests/data/missing_recipe.yml` and `tests/data/action_invalid.yml`
still fail parsing, now via the Task 2.1 manifest-layer error. Keep the existing
`is_err()` assertions in `tests/ast_tests/manifest_files.rs`.
- Add an `ir_from_manifest` test, following the patterns in
`tests/ir_from_manifest_tests.rs`, asserting the dependency-only edge has
`action_id: None`, that its `implicit_deps` preserve manifest order, and that
the graph registers no extra `Action`.
- Add a `ninja_gen` test, following the `#[case]` style in
`tests/ninja_gen_unit_tests.rs`, asserting the generated text contains `build
<name>: phony <deps>` and contains no synthetic `command =` line for that node.
- Add a serial-case assertion, following the patterns in
`tests/ninja_gen_integration_tests.rs` and `serial_dependency_*`, confirming a
recipe-less serial node still produces the gate/sidecar chain and a terminal
`build <name>: phony <gate-chain>` statement.
- Add a scenario to `tests/features/manifest.feature` that parses the
dependency-only fixture successfully, mirroring the existing positive-shape
scenarios.
- Add a scenario to `tests/features/ninja.feature`, mirroring "Target and action
deps become implicit Ninja dependencies", asserting the `build <name>: phony …`
line is present.
- Add a negative "does not contain" Then-step in `tests/bdd/steps/ninja.rs`,
reusing `get_ninja_content`/`assert_optional_contains`, and use it to assert
that no synthetic `command =` line is emitted.
- Add a CLI round-trip test in `tests/runner_tests.rs`, following
`run_generate_subcommand_writes_file`, confirming `run` succeeds and the
generated file contains the `phony` build statement for the dependency-only
node.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!