Skip to content

frontier gate blind to optional / feature-gated / cfg-target / build-dependency edges #2

Description

@guycorbaz

Context

The frontier CI gate added in Story 1.1 (D47) enforces the dependency frontier by reading cargo tree -p <pkg> -e normal --depth 1 --charset utf8 --locked and flagging forbidden crates (anyhow/axum/sqlx/askama in opencmdb-core; xtask in any product crate).

Limitation (latent false-negative)

That cargo tree invocation resolves only:

  • the default feature set — a banned crate declared optional = true or behind a non-default feature is absent from the graph;
  • the host target — a banned crate under [target.'cfg(...)'.dependencies] for another platform is filtered out;
  • normal edges (-e normal) — a banned crate declared as a [build-dependencies] entry (usable from build.rs) is excluded.

In each case the manifest genuinely names the forbidden crate, but the gate stays GREEN. This is the reflex gate's (D53) assumed boundary — it is not a proof.

Impact today

Zero. opencmdb-core declares no features, no cfg-target deps, and no build.rs. This is preventive.

Why not fixed now

Closing it properly needs a feature-matrix approach: --all-features alone risks false positives from workspace feature unification (a shared dep's feature enabled elsewhere surfacing a banned sub-dep under core's tree). Needs design before implementation.

Action

Revisit before the gate is relied upon for a core crate that grows optional/feature-gated/cfg-target/build dependencies. Discovered by adversarial code review of Story 1.1 (2026-07-19); recorded in _bmad-output/implementation-artifacts/deferred-work.md.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions