fix: make consumes_absent respect produces_kinds when flagging a real gap (2.5.68)

[vdevanathan-olo]

Fixes #736

Summary

consumes_absent's expected flag now checks a producer's own produces_kinds gate before flagging an absent artifact as a real gap, so a kind-tagged unit that correctly never produces a given artifact no longer gets a false "real gap" alarm on the next stage's directive.

Changes

• splitConsumesByPresence(consumes, scope, codekbCtx) → splitConsumesByPresence(consumes, scope, codekbCtx, unitKind), mirroring resolveProduces's existing unitKind parameter.
• producerOnPath's computation now also checks filterProducesByKind(producer.produces_kinds, [artifact], unitKind).length > 0 — a producing stage being on the active scope's path is necessary but no longer sufficient; it must also actually be scoped to produce this specific artifact for this unit's kind.
• buildRunStageDirective (the one call site) already received unitKind as a parameter and already passed it to resolveProduces — it now passes it through to splitConsumesByPresence too.
• filterProducesByKind returns its input unchanged when unitKind is null, so an untagged unit or a stage with no produces_kinds map sees byte-for-byte identical behaviour — this is a strict narrowing of the true case, not a behaviour change for anything that isn't kind-gated.
• Regenerated dist/ via bun scripts/package.ts (not hand-edited).
• Version 2.5.68 (README badge + CHANGELOG).

User experience

Before: a ui-kind unit correctly never produces business-rules.md (functional-design's own produces_kinds map scopes it to [service, spec, library], excluding ui). The next stage that consumes business-rules as required: true (e.g. nfr-requirements) still flags it expected: false — "a real gap, surface it per the recovery protocol" — on its own run-stage directive, because functional-design itself did run. The conductor is pointed at a recovery protocol for an artifact that was never supposed to exist.

After: the same ui-kind unit's consumes_absent entry for business-rules reports expected: true — its absence is by design, not a gap. A service-kind (or untagged) unit's identical absence at the same stage is unaffected and still correctly reports expected: false, since business-rules genuinely is in scope for that kind.

Upgrade: re-copy your dist/<harness>/ shell into the project.

Checklist

• I have reviewed the contributing guidelines
• I have performed a self-review of this change
• Changes have been tested
• Changes are documented

Test Plan

• New regression test tests/unit/t279-consumes-absent-kind-gate.test.ts: (1) a ui-kind unit's absent business-rules is expected: true, not a false alarm — confirmed RED against the pre-fix dist/, then GREEN after regenerating; (2) a service-kind unit's identical absence stays expected: false (real gap, regression anchor); (3) an untagged unit's identical absence also stays expected: false (unchanged, regression anchor).
• bun test tests/unit/t113.test.ts tests/unit/t116-directive-path-resolution.test.ts tests/unit/t207-unit-kind-schema.test.ts tests/unit/t279-consumes-absent-kind-gate.test.ts tests/unit/gen-coverage-registry.test.ts tests/unit/t68-version-changelog-sync.test.ts → 137 pass, 0 fail.
• bun run check (package.ts --check + typecheck + lint) → clean (the only lint output is 3 pre-existing infos in an unrelated file, t267-usage.test.ts, unaffected by this branch).
• bun test tests/unit/t208-unit-kind-pruning.test.ts tests/unit/t236-ensemble-evidence-gate.test.ts → confirmed the 21 failures in these two files reproduce identically on a pristine, unmodified v2 checkout (unrelated environment-specific failures — missing question-flow/contribution-file fixtures, not this change) — not a regression from this branch.

Acknowledgment

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the project license.

[leandrodamascena]

Thank you for reporting this issue and for taking the time to isolate it with a focused implementation and regression test. The bug was valid against this branch's original base, e3bf9be1.

Since then, #617, merged as 327d3626, introduced an earlier kind-aware filter in resolveConsumes(). When a per-unit producer's produces_kinds excludes the current Unit kind, the artifact is omitted before presence splitting, so it appears in neither consumes nor consumes_absent.

This preserves expected:true for its original meaning: an artifact is absent because its producer is outside the active scope. A kind-inapplicable artifact is not an input for that Unit and is therefore omitted entirely.

I reproduced #736's exact ui Unit / nfr-requirements / business-rules.md scenario on current v2:

{"stage":"nfr-requirements","unit":"web","businessRulesAbsent":[]}

The merged t278-per-unit-wave suite also pins this omission behavior. Verification completed:

• PR head focused suites: 137 passed
• Current v2 affected suites: 108 passed
• Package parity passed on both
• Exact [Bug]: consumes_absent's expected flag doesn't check produces_kinds — a kind-gated unit gets a false "real gap" flag for an artifact it was never supposed to produce #736 reproduction passed on current v2

Rebasing this PR would make its implementation redundant and its expected:true assertion conflict with the current contract. For that reason, I'm going to close this PR as superseded by #617 and treat #736 as fixed by that merged implementation.

Thank you again for identifying the original integration gap and contributing the analysis and test coverage.