Lower target and action deps (3.14.3)

[leynos]

Summary

This branch implements roadmap task (3.14.3) by lowering target and action deps into a dedicated implicit-dependency class in the IR and generated Ninja output. It keeps sources as the explicit recipe-input class used by $in and {{ ins }}, while deps now affect dependency ordering, rebuild decisions, and cycle detection without appearing in recipe arguments.

Roadmap task: (3.14.3)
Execplan: docs/execplans/3-14-3-lower-target-and-action-deps.md

Review walkthrough

• Start with src/ir/graph.rs and src/ir/from_manifest.rs to see the new BuildEdge.implicit_deps field and manifest lowering from target.deps.
• Then review src/ir/cycle.rs and src/ninja_gen.rs for cycle traversal and Ninja | <implicit_deps> rendering.
• Check src/manifest/render.rs and src/ir/cmd_interpolate.rs for the related {{ ins }} / {{ outs }} placeholder preservation needed by the documented recipe contract.
• Finish with tests/ir_from_manifest_tests.rs, tests/ninja_gen_tests.rs, tests/features/ninja.feature, and tests/bdd/steps/ir.rs for unit, generator, and behavioural coverage.
• The user and maintainer-facing contract is documented in docs/users-guide.md, docs/developers-guide.md, docs/netsuke-design.md, and docs/formal-verification-methods-in-netsuke.md.

Validation

• cargo test --workspace: passed after the IR field addition.
• cargo test --test ir_from_manifest_tests: passed with 15 tests after manifest lowering.
• cargo test -p netsuke ir::cycle: passed after implicit-dependency cycle traversal.
• cargo test --test ninja_gen_tests: passed after Ninja emission updates.
• cargo test --test bdd_tests implicit: passed after behavioural coverage was added.
• make check-fmt: passed in the final gate.
• make lint: passed in the final gate.
• make test: passed in the final gate.
• make markdownlint: passed in the final gate.
• make nixie: passed in the final gate.
• coderabbit review --agent: completed with zero findings.

Notes

make fmt still triggers a pre-existing repository-wide Markdown formatting backlog and rewrites unrelated documentation before failing. This branch restored that unrelated churn and used the non-mutating gates above as the applicable completion checks.

No new external crate dependencies were added. The planned proptest coverage was replaced with deterministic bounded cycle coverage because proptest is not currently in the dependency graph and the execplan requires explicit approval before adding dependencies.

Summary by Sourcery

Lower manifest target and action deps into a dedicated implicit-dependency class in the IR and generated Ninja output, aligning cycle detection, recipe interpolation, tests, and documentation with the intended dependency semantics.

New Features:

• Introduce implicit_deps on IR build edges to represent manifest deps separately from explicit sources inputs.
• Support manifest deps for both targets and actions as implicit dependencies that appear in generated Ninja files using Ninja's | syntax.

Enhancements:

• Update cycle detection to traverse both explicit inputs and implicit dependencies while keeping order-only dependencies excluded.
• Preserve {{ ins }} and {{ outs }} placeholders through manifest rendering so recipe interpolation can expand only explicit sources and outputs.
• Clarify and expand user, developer, design, and formal-verification documentation around dependency classes and cycle participation, and mark roadmap item 3.14.3 as complete.

Tests:

• Add IR unit tests to ensure manifest deps populate implicit dependencies and do not affect explicit recipe inputs.
• Extend cycle-detection tests to cover implicit-only, mixed, missing-implicit, and bounded small cycles.
• Add Ninja generation tests and BDD scenarios validating implicit dependency lowering, Ninja edge formatting, and recipe interpolation behaviour.

[coderabbitai]

Warning

Review limit reached

@lodyai[bot], we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 22 minutes and 26 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: fa73a8e6-36bc-48e7-bb12-5f1da748c223

📥 Commits

Reviewing files that changed from the base of the PR and between 50c93e4 and 0ca3452.

📒 Files selected for processing (3)

• docs/users-guide.md
• src/ir/cycle.rs
• src/ir/from_manifest.rs

Walkthrough

Implement lowering of manifest deps into IR BuildEdge.implicit_deps, include implicit deps in cycle traversal (excluding order-only deps), render implicit deps as Ninja | segments, ensure ins/outs exist for command templates, and update tests and documentation to validate and record the change.

Changes

Implicit dependencies implementation and lowering

Layer / File(s)	Summary
IR data structure for implicit dependencies src/ir/graph.rs, docs/netsuke-design.md, README.md, docs/developers-guide.md	BuildEdge gains a public implicit_deps: Vec<Utf8PathBuf> field and docs clarify it maps to Ninja `
Populate implicit deps from manifest src/ir/from_manifest.rs, tests/data/implicit_deps.yml, tests/ir_from_manifest_tests.rs	Convert target.deps to Utf8PathBuf and populate BuildEdge.implicit_deps during graph construction; add fixtures and tests exercising manifest->IR lowering.
Cycle detection traversal and tests src/ir/cycle.rs	CycleDetector::visit now traverses edge.inputs and edge.implicit_deps; test helpers accept implicit_deps and new tests cover implicit-only, mixed, self-edge, missing-dep, and bounded-cycle scenarios.
Ninja generator output for implicit dependencies src/ninja_gen.rs, tests/ninja_gen_tests.rs	DisplayEdge conditionally appends `
Command template variable handling src/manifest/render.rs, src/ir/cmd_interpolate.rs	Introduce render_recipe_str_with to guarantee ins/outs keys in rendering context; centralise find_substitution to handle $in/$out and placeholder tokens while preserving backtick-delimited sections; add tests for placeholder preservation and token replacement.
BDD, feature and unit tests tests/data/implicit_deps.yml, tests/features/ninja.feature, tests/bdd/steps/ir.rs, tests/ir_from_manifest_tests.rs, tests/ir_tests.rs, tests/ninja_gen_tests.rs, tests/bdd_tests.rs, tests/ninja_snapshot_tests.rs	Add fixtures and feature scenario asserting implicit deps appear in IR and Ninja output; add BDD step assertions; add/rstests verify manifest deps populate implicit_deps and do not contribute to recipe inputs; update existing tests to initialise implicit_deps: Vec::new(); add an Insta snapshot for Ninja output.
Documentation and roadmap docs/developers-guide.md, docs/formal-verification-methods-in-netsuke.md, docs/users-guide.md, docs/execplans/3-14-3-lower-target-and-action-deps.md, docs/roadmap.md, docs/netsuke-design.md	Add "IR dependency classes" section; clarify cycle-participation contract includes sources and deps but excludes order-only deps; publish ExecPlan and mark roadmap task 3.14.3 complete.

Sequence Diagram(s)

sequenceDiagram
  participant UserManifest
  participant BuildGraph
  participant BuildEdge
  participant CycleDetector
  participant NinjaGenerator

  UserManifest->>BuildGraph: provide `sources`, `deps`, `order_only_deps`
  BuildGraph->>BuildEdge: set `inputs` from `sources`, `implicit_deps` from `deps`
  CycleDetector->>BuildEdge: traverse `inputs` and `implicit_deps` (not `order_only_deps`)
  BuildEdge->>NinjaGenerator: render `inputs`, emit `| implicit_deps` if non-empty, append `|| order_only_deps`

Loading

Suggested labels

Roadmap

Possibly related PRs

• leynos/netsuke#38: Touches src/ninja_gen.rs formatting logic relevant to emitting implicit dependency | segments.

Poem

A graph that builds, now implicit and true,
Dependencies lurk where the cycle-check flew,
From manifest down to the Ninja's |,
Deps trigger rebuilds without {{ ins }} to lie,
The blueprint complete—the roadmap ascends! 📋✨

🚥 Pre-merge checks | ✅ 18 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
User-Facing Documentation	⚠️ Warning	Example comments contradict formal definitions: Example 1 calls deps "explicit" (should be implicit); Example 2 calls sources "implicit" (should be explicit).	Fix YAML example comments: Example 1 change deps: # Explicit dependencies to deps: # Implicit dependencies; Example 2 change sources: # Implicit dependencies to sources: # Explicit recipe inputs.
Observability	⚠️ Warning	Cycle detection now traverses implicit_deps with new failure modes but missing_dependencies are only logged at debug level, not surfaced to users without cycles.	Add error reporting for unresolved implicit dependencies independently of cycles; emit structured error messages including missing_dependencies; add tracing at info level for dependency resolution issues.

✅ Passed checks (18 passed)

Check name	Status	Explanation
Title check	✅ Passed	The PR title clearly describes the main change and includes the roadmap item reference (3.14.3) as required.
Description check	✅ Passed	The description comprehensively relates to the changeset, documenting the implementation of roadmap task 3.14.3 with detailed explanations of affected modules and validation steps.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Testing (Overall)	✅ Passed	Tests substantively exercise implicit_deps: IR tests verify population; cycle tests detect implicit-only cycles; ninja tests assert | syntax; snapshots and BDD tests validate end-to-end flow.
Developer Documentation	✅ Passed	Developers guide documents IR dependency classes; design documents refined; roadmap 3.14.3 marked complete; execplan provided with progress tracking; module docstrings expanded.
Module-Level Documentation	✅ Passed	All 12 modified Rust modules carry docstrings with purpose, utility/function, and component relationships clearly explained using Rust's //! documentation syntax.
Testing (Unit And Behavioural)	✅ Passed	Comprehensive test suite across unit (cycle, interpolation), integration (manifest→IR), ninja generation, BDD, and snapshot tests with runtime assertions validates implicit dependency behaviour.
Testing (Property / Proof)	✅ Passed	Execplan required proptest for the cycle-detection invariant but explicitly allows bounded deterministic tests if proptest approval is not obtained. Decision log confirms this substitution was made.
Testing (Compile-Time / Ui)	✅ Passed	Snapshot test implicit_deps_manifest_ninja validates Ninja | <implicit_deps> syntax with meaningful assertions; no trybuild needed (non-proc-macro library).
Unit Architecture	✅ Passed	Dependencies injected, fallibility explicit in Result types. Queries and commands cleanly separated. No global state. Module responsibilities documented. Tests use query patterns properly.
Domain Architecture	✅ Passed	IR segregated from infrastructure: manifests pre-rendered before IR lowering, placeholders in adapter layer, domain logic focused on cycles and interpolation, no infrastructure leaks.
Security And Privacy	✅ Passed	PR introduces implicit dependency tracking without secrets, injection risks, or auth gaps. Type-safe paths, proper shell escaping, backtick-protected interpolation, no credential exposure.
Performance And Resource Use	✅ Passed	Cycle detection remains O(V+E) with implicit edges; all allocations and data growth are linear in manifest size; no unbounded resources, hot-path blocking, or I/O patterns introduced.
Concurrency And State	✅ Passed	PR is purely functional IR graph construction with no async, locks, shared mutable state, or concurrency patterns. All state is locally owned and test fixtures are isolated per scenario.
Architectural Complexity And Maintainability	✅ Passed	Field addition follows existing dependency-class patterns. Clean layering, no circular deps. Test duplication consolidated. Proportional decomposition. No unnecessary abstractions, traits, or crates.
Rust Compiler Lint Integrity	✅ Passed	PR maintains lint integrity: no new allow/expect directives hide unused code; all new helpers properly used; no artificial references or dead code found.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch 3-14-3-lower-target-and-action-deps

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[sourcery-ai]

Sorry @leynos, you have reached your weekly rate limit of 2500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[leynos]

@coderabbitai Please suggest a fix for this issue and supply a prompt for an AI coding agent to enable it to apply the fix. Include the file and symbol names indicated in the issue at the head of your response.

Code Duplication

src/ir/cycle.rs:

What lead to degradation?

The module contains 2 functions with similar structure: tests.cycle_detector_records_missing_dependencies,tests.cycle_detector_records_missing_implicit_dependencies

Why does this problem occur?

Duplicated code often leads to code that's harder to change since the same logical change has to be done in multiple functions. More duplication gives lower code health.

How to fix it?

A certain degree of duplicated code might be acceptable. The problems start when it is the same behavior that is duplicated across the functions in the module, ie. a violation of the Don't Repeat Yourself (DRY) principle. DRY violations lead to code that is changed together in predictable patterns, which is both expensive and risky. DRY violations can be identified using CodeScene's X-Ray analysis to detect clusters of change coupled functions with high code similarity. Read More
Once you have identified the similarities across functions, look to extract and encapsulate the concept that varies into its own function(s). These shared abstractions can then be re-used, which minimizes the amount of duplication and simplifies change.

[leynos]

@coderabbitai Please suggest a fix for this issue and supply a prompt for an AI coding agent to enable it to apply the fix. Include the file and symbol names indicated in the issue at the head of your response. Ensure that this is validated against the current version of the codegraph.

If further refinement to address this finding would be deleterious, please supply a clear explanatory one to two paragraph markdown message I can paste into the CodeScene web ui's diagnostic suppression function so this diagnostic can be silenced.

Code Duplication

src/ir/cycle.rs:

What lead to degradation?

The module contains 2 functions with similar structure: tests.cycle_detector_records_missing_dependencies,tests.cycle_detector_records_missing_implicit_dependencies

Why does this problem occur?

Duplicated code often leads to code that's harder to change since the same logical change has to be done in multiple functions. More duplication gives lower code health.

How to fix it?

A certain degree of duplicated code might be acceptable. The problems start when it is the same behavior that is duplicated across the functions in the module, ie. a violation of the Don't Repeat Yourself (DRY) principle. DRY violations lead to code that is changed together in predictable patterns, which is both expensive and risky. DRY violations can be identified using CodeScene's X-Ray analysis to detect clusters of change coupled functions with high code similarity. Read More
Once you have identified the similarities across functions, look to extract and encapsulate the concept that varies into its own function(s). These shared abstractions can then be re-used, which minimizes the amount of duplication and simplifies change.

[leynos]

@coderabbitai Please suggest a fix for this issue and supply a prompt for an AI coding agent to enable it to apply the fix. Include the file and symbol names indicated in the issue at the head of your response. Ensure that this is validated against the current version of the codegraph.

If further refinement to address this finding would be deleterious, please supply a clear explanatory one to two paragraph markdown message I can paste into the CodeScene web ui's diagnostic suppression function so this diagnostic can be silenced.

Code Duplication

src/ir/cycle.rs:

What lead to degradation?

The module contains 2 functions with similar structure: tests.cycle_detector_records_missing_dependencies,tests.cycle_detector_records_missing_implicit_dependencies

Why does this problem occur?

Duplicated code often leads to code that's harder to change since the same logical change has to be done in multiple functions. More duplication gives lower code health.

How to fix it?

A certain degree of duplicated code might be acceptable. The problems start when it is the same behavior that is duplicated across the functions in the module, ie. a violation of the Don't Repeat Yourself (DRY) principle. DRY violations lead to code that is changed together in predictable patterns, which is both expensive and risky. DRY violations can be identified using CodeScene's X-Ray analysis to detect clusters of change coupled functions with high code similarity. Read More
Once you have identified the similarities across functions, look to extract and encapsulate the concept that varies into its own function(s). These shared abstractions can then be re-used, which minimizes the amount of duplication and simplifies change.

[leynos]

@coderabbitai Please investigate the cause of the following issue using codegraph exploration and research, identify a fix and provide an AI coding agent prompt for the fix:

error: this argument is passed by value, but not consumed in the function body
Error:    --> src/ir/cycle.rs:179:18
    |
179 |         targets: HashMap<Utf8PathBuf, BuildEdge>,
    |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_pass_by_value
    = note: requested on the command line with `-D clippy::needless-pass-by-value`
help: consider taking a reference instead
    |
179 |         targets: &HashMap<Utf8PathBuf, BuildEdge>,
    |                  +

error: could not compile `netsuke` (lib test) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
make: *** [Makefile:32: lint] Error 101
Error: Process completed with exit code 2.

[sourcery-ai]

Reviewer's Guide

Implements roadmap task 3.14.3 by introducing an explicit implicit-dependency class (implicit_deps) on IR build edges, wiring manifest deps into it, making cycle detection traverse it, emitting it as Ninja implicit dependencies, and updating tests and docs to reflect the new dependency and recipe-interpolation contracts.

File-Level Changes

Change	Details	Files
Extend the IR build graph to represent implicit dependencies separately from explicit inputs.	Add implicit_deps: Vec<Utf8PathBuf> to BuildEdge in the IR graph, documented as implicit dependencies that do not enter recipes. Update all BuildEdge construction sites in tests and doctests to initialise implicit_deps (usually Vec::new()). Clarify the BuildEdge struct documentation in docs/netsuke-design.md to describe inputs as explicit recipe inputs and implicit_deps as Ninja `	deps kept separate from$in/{{ ins }}`.
Lower manifest-level deps into the new IR implicit-dependency field without affecting explicit recipe inputs or interpolation.	In manifest-to-IR lowering, convert Target.deps to paths and populate BuildEdge.implicit_deps alongside existing inputs and order_only_deps. Add unit tests to assert that deps from both targets and actions populate implicit_deps, that inputs reflect only sources, and that phony flags are preserved. Ensure manifest rendering preserves {{ ins }} and {{ outs }} placeholders by wrapping recipe rendering in a helper that injects default placeholder values, so later IR interpolation can substitute them correctly from explicit inputs/outputs. Add tests to verify that recipe commands interpolate $in and {{ ins }} using only sources, and that deps never appear in the command text while still populating implicit_deps. Add BDD steps and a manifest fixture to assert graph-level inputs vs implicit_deps for targets and actions and to verify Ninja output and recipe interpolation behaviour end-to-end.	src/ir/from_manifest.rs tests/ir_from_manifest_tests.rs src/manifest/render.rs tests/bdd/steps/ir.rs tests/features/ninja.feature tests/data/implicit_deps.yml
Update cycle detection so that implicit dependencies participate in cycle discovery and missing-dependency reporting.	Change the cycle detector to traverse both inputs and implicit_deps when visiting dependencies of a node. Refactor and extend cycle tests to construct edges with both classes, including helpers to build edges, insert cycle edges, and assert missing dependencies. Add tests for cycles that use only implicit deps, mixed explicit/implicit cycles, and bounded cycles of varying lengths where one edge uses an implicit dep, ensuring they are all detected. Add tests ensuring missing dependencies are recorded for both explicit and implicit deps without affecting other behaviour.	src/ir/cycle.rs
Emit Ninja build lines that include implicit dependencies in the correct position and document the dependency-class and cycle contracts.	Update Ninja edge formatting to render `	<implicit_deps>after explicit inputs but before

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

docs/execplans/3-14-3-lower-target-and-action-deps.md (1)

12-20: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Fix MD013 line-length violations in docs/execplans/3-14-3-lower-target-and-action-deps.md and correct the lint-passed claim

Markdownlint (markdownlint-cli2, rule MD013, line_length: 80) flags this file with over-limit lines at 13 (98 chars), 95 (104 chars), and 284 (91 chars); rewrap those lines to <=80 characters.

Update the “make markdownlint … passed” statement in the Progress/QA text to match the current lint result for this file.

Triage: [type:docstyle]

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/execplans/3-14-3-lower-target-and-action-deps.md` around lines 12 - 20,
Reflow any over-long sentences in the docs section for Roadmap item `3.14.3` so
no line exceeds 80 characters (specifically shorten the long sentences that
currently render at ~98, 104, and 91 chars), and update the Progress/QA "make
markdownlint … passed" claim to reflect the actual lint result for this file;
edit the markdown under the Roadmap item `3.14.3` header and the Progress/QA
paragraph to wrap text to <=80 cols and correct the lint status text
accordingly.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@docs/execplans/3-14-3-lower-target-and-action-deps.md`:
- Around line 12-20: Reflow any over-long sentences in the docs section for
Roadmap item `3.14.3` so no line exceeds 80 characters (specifically shorten the
long sentences that currently render at ~98, 104, and 91 chars), and update the
Progress/QA "make markdownlint … passed" claim to reflect the actual lint result
for this file; edit the markdown under the Roadmap item `3.14.3` header and the
Progress/QA paragraph to wrap text to <=80 cols and correct the lint status text
accordingly.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 5257f0e4-ef7a-4b92-b999-46189bb0812d

📥 Commits

Reviewing files that changed from the base of the PR and between 5869bc6 and 4532bbf.

📒 Files selected for processing (2)

• docs/execplans/3-14-3-lower-target-and-action-deps.md
• src/ir/cmd_interpolate.rs

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
echo "=== README.md (deps-related lines) ==="
grep -n -i "deps\|implicit\|explicit\|sources" README.md | head -60

echo ""
echo "=== tests/ninja_snapshot_tests.rs ==="
cat tests/ninja_snapshot_tests.rs

echo ""
echo "=== snapshot files present ==="
fd "\.snap$" tests/

Length of output: 6051

---

---

@leynos Both checks are confirmed resolved in the latest commit.

Check	Status
User-Facing Documentation	✅ README.md line 84 now reads deps: implicit dependencies — trigger rebuilds but are not passed to $in/{{ ins }}; map to Ninja |
Testing (Compile-Time / UI)	✅ implicit_deps_manifest_ninja_snapshot is present in tests/ninja_snapshot_tests.rs and its snapshot file ninja_snapshot_tests__implicit_deps_manifest_ninja.snap has been committed

No further work is required for either item.

[leynos]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@tests/ninja_snapshot_tests.rs`:
- Around line 133-152: Add an explicit assertion that the generated Ninja output
contains implicit deps using the `|` syntax: after the `let ninja_content =
ninja_gen::generate(&ir)?;` line in the `implicit_deps_manifest_ninja_snapshot`
test, call `ensure!(ninja_content.contains(" | "), "expected implicit deps
(Ninja `|` syntax) in output:\n{ninja_content}");` and import `ensure!` from
`anyhow` if not already present; reference `ninja_content` and the test function
name to locate where to insert this check.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: e6c4e8b2-5b7f-4f49-bd4a-cf1d90fc5236

📥 Commits

Reviewing files that changed from the base of the PR and between 4532bbf and 467d634.

⛔ Files ignored due to path filters (1)

• tests/snapshots/ninja/ninja_snapshot_tests__implicit_deps_manifest_ninja.snap is excluded by !**/*.snap

📒 Files selected for processing (3)

• README.md
• docs/execplans/3-14-3-lower-target-and-action-deps.md
• tests/ninja_snapshot_tests.rs

[leynos]

@coderabbitai Have the following failed checks now been resolved?

If further work is required, please provide an AI agent prompt for the remaining work to be done to address these failures.

Do not treat warnings as optional or aspirational. Where a change is out of scope for this PR, propose a GitHub issue unless one exists already.

❌ Failed checks (3 errors, 1 warning)

Check name	Status	Explanation	Resolution
Testing (Overall)	❌ Error	Snapshot test lacks explicit assertion for Ninja `	` syntax; snapshot matching alone cannot guarantee format preservation during refactoring.
Module-Level Documentation	❌ Error	8 of 12 modules lack adequate documentation per criteria: 5 source modules and 3 test modules use single-line docstrings that omit relationship context to other components.	Expand docstrings in src/ir/{cmd_interpolate,cycle,from_manifest,graph}, src/manifest/render, tests/{bdd/steps/ir,ir_from_manifest,ir}_tests to document integration points, field semantics, and validation scope.
Unit Architecture	❌ Error	The snapshot test implicit_deps_manifest_ninja_snapshot lacks the explicit ensure! assertion for the `	` syntax in Ninja output, as requested in review comments. This reduces test clarity.
Testing (Compile-Time / Ui)	⚠️ Warning	Snapshot test lacks explicit semantic assertion for implicit deps `	` syntax as requested in review comments; relies only on snapshot.

[leynos]

@coderabbitai Please suggest a fix for the following concern and provide an AI coding agent prompt for the fix:

Observability ⚠️ Warning Cycle detection now traverses implicit_deps with new failure modes but missing_dependencies are only logged at debug level, not surfaced to users without cycles. Add error reporting for unresolved implicit dependencies independently of cycles; emit structured error messages including missing_dependencies; add tracing at info level for dependency resolution issues.