extends: org also fails to layer dependencies.require from parent (same root as #1198)

[danielmeppiel]

Summary

Same root cause as #1198 (unmanaged_files not layered through extends: org). The dependencies.require field is also dropped when a repo apm-policy.yml declares extends: org and the org floor declares dependencies.require.

Repro

# Org floor (e.g. org/.github/apm-policy.yml)
version: 1
dependencies:
  require:
    - secure-baseline

# Repo override (e.g. some-app/apm-policy.yml)
version: 1
extends: org
# (does NOT redeclare dependencies.require)

Run apm audit --ci --policy ./apm-policy.yml in the repo with secure-baseline removed from apm.yml. Expected: required-packages check fails with secure-baseline missing from manifest. Actual: check passes with No required packages configured — the org's required list never made it into the layered policy.

Workaround (proven)

Redeclare in the repo override:

version: 1
extends: org
dependencies:
  require:
    - secure-baseline   # workaround: extends: org doesn't layer this

Why this matters

Defeats the "required floor" governance pattern that the policy reference (https://microsoft.github.io/apm/enterprise/policy-reference/) is documented to support. Org wants to mandate secure-baseline everywhere; extends: org is the documented mechanism; today it silently downgrades the floor.

Likely fix location

Same place as #1198 — the inheritance-merge code path that handles extends:. Looks like an additive/union merge is missing for dependencies.require (and possibly dependencies.deny, untested).

Context

Discovered while wiring a 5-beat enterprise demo. Repro is reproducible end-to-end on a public org. Same workaround as #1198 unblocks; would prefer a fix so policy authors don't have to remember to redeclare two separate fields per override file.

[github-actions]

Triage decision

accept

Proposed labels

theme/governance
area/audit-policy
type/bug
status/accepted
priority/high

Milestone

0.12.5 (recommended; unable to apply programmatically -- milestone number not resolvable without authenticated CLI)

Suggested next action

Fix inheritance.py to apply additive union semantics to dependencies.require (and verify dependencies.deny) when merging a child policy that omits the field, so the parent's required list is inherited rather than dropped.

Suggested issue comment

Thanks for the repro and the link to #1198 -- this is the same root cause applied to a different policy field.

The inheritance merge code lacks additive-union semantics for `dependencies.require`: when a child policy omits the `dependencies:` block (or declares it without `require:`), the parent's required list is dropped instead of inherited. The same logic may affect `dependencies.deny` as well (worth verifying in the same fix).

**Accepted.** The fix for #1198 (sentinel-aware field handling) and this issue can land in the same PR since they share the root cause in `inheritance.py`. The fix for `dependencies.require` specifically needs additive semantics: if the child does not declare the field, inherit the parent's list; if it does declare it, take the union (child adds to, not replaces, the org floor).

This directly defeats the "required floor" governance pattern documented at (microsoft.github.io/redacted) -- org-level mandatory packages should not be silently droppable by any repo override.

Target: 0.12.5 patch alongside #1198. A regression test with the org-requires + child-omits fixture from this report would be a valuable addition to the `inheritance.py` test suite.

Per-lens notes (collapsed)

DevX UX Expert -- User-Need Reviewer

dependencies.require is the mechanism for enforcing "these packages must always be installed" at the org level. The extends: org contract promises that a repo override inherits this floor unless it explicitly overrides it. A child that adds only a deny pattern (an unrelated change) should not silently drop the required list. This is the same mental model break as #1198 but applied to the package requirement surface.

Supply Chain Security Expert -- Risk-Surface Reviewer

dependencies.require enforces baseline package presence -- a supply chain governance mechanism. Silently dropping the org's required list when a child override is present means package-level governance can be circumvented without any explicit override declaration. theme/governance, area/audit-policy required. Same risk profile as #1198.

OSS Growth Hacker -- Contributor-Tone Reviewer

Not activated -- danielmeppiel is a COLLABORATOR with extensive prior interactions.

Python Architect -- Architecture Reviewer

Same root cause as #1198 in inheritance.py. For list-valued fields like dependencies.require, the correct semantics is additive union (parent list + child additions), not replacement. The fix should be verified for dependencies.deny too (which may need intersection or union semantics depending on whether "more deny = safer"). Both issues (#1198 and this one) should land in the same PR to close the root cause systematically. Cross-cutting: the parser layer must emit None for absent list fields to enable the sentinel check. Feasible; status/accepted.

Doc Writer -- Documentation Reviewer

Not activated -- this is an internal bug fix in the inheritance merge logic. The policy reference already documents the intended inheritance behavior; no new pages needed. A CHANGELOG entry noting the fix is sufficient.

APM CEO -- Triage Arbiter

Same root cause, same priority, same milestone as #1198. These two issues should be treated as one fix effort. The "required floor" governance pattern is documented and marketed to enterprise customers -- a silent drop of that floor is priority/high. Accepting for 0.12.5 patch. Encourage the fix to land in the same PR as #1198 to close the root cause systematically across all affected policy fields.

{
  "decision": "accept",
  "decision_detail": "",
  "theme": "theme/governance",
  "areas": ["area/audit-policy"],
  "type": "type/bug",
  "status": "status/accepted",
  "priority": "priority/high",
  "preserved_labels": [],
  "milestone": "0.12.5",
  "next_action": "Fix inheritance.py to apply additive union to dependencies.require (and verify dependencies.deny) when child omits the field; co-land with #1198 fix.",
  "comment_markdown": "Thanks for the repro and the link to #1198 -- this is the same root cause applied to a different policy field.\n\nThe inheritance merge code lacks additive-union semantics for `dependencies.require`: when a child policy omits the `dependencies:` block (or declares it without `require:`), the parent's required list is dropped instead of inherited. The same logic may affect `dependencies.deny` as well (worth verifying in the same fix).\n\n**Accepted.** The fix for #1198 (sentinel-aware field handling) and this issue can land in the same PR since they share the root cause in `inheritance.py`. The fix for `dependencies.require` specifically needs additive semantics: if the child does not declare the field, inherit the parent's list; if it does declare it, take the union (child adds to, not replaces, the org floor).\n\nThis directly defeats the \"required floor\" governance pattern documented at (microsoft.github.io/redacted) -- org-level mandatory packages should not be silently droppable by any repo override.\n\nTarget: 0.12.5 patch alongside #1198. A regression test with the org-requires + child-omits fixture from this report would be a valuable addition to the `inheritance.py` test suite."
}

---

Triage status: agentic proposal pending human ratification.
Silence is approval. Maintainers can:

• Override any label or milestone above by editing it directly --
  human edits are authoritative and will not be reverted on
  subsequent runs.
• Re-trigger triage by applying the status/needs-triage label, or
  by removing status/triaged to enroll the issue in the next
  daily sweep.

Posted by the Triage Panel workflow. See .apm/skills/apm-triage-panel for the panel skill.

Note

🔒 Integrity filter blocked 12 items

The following items were blocked because they don't meet the GitHub integrity level.

• #1120 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1122 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1130 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1138 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1156 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1157 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1195 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1203 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1209 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1210 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1220 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #1222 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

Generated by Triage Panel · ● 1.1M · ◷