chore(deps-dev): bump @elvatis_com/aahp from 3.8.1 to 3.9.0

[dependabot]

Bumps @elvatis_com/aahp from 3.8.1 to 3.9.0.

Release notes

Sourced from @​elvatis_com/aahp's releases.

AAHP v3.9.0

Release v3.9.0. See CHANGELOG.md for details.

Changelog

Sourced from @​elvatis_com/aahp's changelog.

[3.9.0] - 2026-07-26

Acceptance-criteria lifecycle, plus an advisory report that is deliberately not a gate

Added

• Specification Section 8.7 defines the acceptance-criteria lifecycle: one canonical Acceptance criteria section per task, - [ ] while a criterion is unresolved, - [x] only on evidence, and, before a task becomes done or a linked issue closes, every remaining criterion completed, explicitly waived ((waived: rationale)), or moved to a linked open follow-up ((follow-up: T-042)). Completion criteria and Definition of done stay recognized as legacy aliases with a documented rename path.
• aahp criteria [path], an ADVISORY report over the lifecycle, backed by scripts/report-acceptance-criteria.mjs. It is not part of aahp check, it has no enforcing mode, and it always exits 0 whatever it finds; the known non-zero exits are the report failing to run at all (an unparseable config, or no git work tree). Best effort by construction, which is why it is advisory and gates nothing. It reports three lifecycle defects (legacy-heading, plain-bullets, unresolved-on-done) and ten comprehension defects so that input it could not read is never presented as a clean document: config-unusable, include-unusable, no-files-matched, file-unreadable, manifest-missing, manifest-outside-root, manifest-unreadable, unparsed-criteria-section, unbound-criteria-section, and unterminated-fence. It reads tracked files plus the MANIFEST.json task registry and makes no network calls, so a run is complete and deterministic offline.
• The always-exits-0 guarantee holds for every input the report accepts. A syntactically valid acceptanceCriteria.include pathspec that git nonetheless refuses (an unknown pathspec magic word, a path outside the repository) is reported as include-unusable rather than throwing out of the process, so the documented pair of non-zero exits is the complete list. The same holds at every level of the configuration: an aahp.config.json that parses but is not a JSON object (null, a string, a number, a boolean, an array) is reported as config-unusable and the report continues on its defaults. A file containing only null previously threw a TypeError out of the process on a config that parses perfectly well, and the other non-object shapes read as no configuration at all without saying so. The same shapes are covered for acceptanceCriteria, for acceptanceCriteria.include, and for acceptanceCriteria.manifest.
• Every configuration finding names aahp.config.json, the only file loadConfig reads. When no config file existed they named package.json, which the loader never opens, so a reader was sent to correct acceptanceCriteria.include in the wrong file.
• acceptanceCriteria.manifest is required to resolve inside the project root. A value containing .. used to be joined to the root and read from outside the work tree; it is now reported as manifest-outside-root and the file is never opened.
• README Section 8.7 publishes the report's known blind spots by name, starting with the most reachable one: the criteria heading must match a recognized phrase exactly after normalization, so ## Acceptance criteria for release opens no section and everything under it is missed in silence. The list also covers the case where a bold line inside a criteria section ends the section and hides every criterion after it. It states in plain words that the report is best effort, that a clean report is not proof the criteria are resolved, and that it must not be used as a merge gate.
• Task ids bind from ATX headings, setext headings, and bold labels, so the three heading forms that appear in hand-written handoff files all scope a criteria section. Anything still unattributable is reported as unbound-criteria-section instead of being exempted from the done-state rule in silence.

... (truncated)

Commits

• 603d726 feat(protocol): acceptance-criteria lifecycle + advisory report, not a gate (...
• 038939b fix(gate): fail Layer 1 on a deleted indexed file, and let lint set its own e...
• 761cd4f chore(handoff): re-verify the trust register (10 rows, 0 downgrades) (#48)
• 7b6e543 fix(gates): one applicability predicate so check, doctor and verify agree (#50)
• b19aa79 chore: untrack supply-chain-guard scanner state (#47)
• 6b2701e docs(rollout): make the propagation playbook project-agnostic (#46)
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[github-actions]

🛡️ supply-chain-guard Scan Report

Property	Value
Target	.
Type	directory
Time	2026-07-27T22:55:24.315Z
Duration	269ms
Risk Score	11/100 (MEDIUM)

Summary

Scanned 82 of 87 files.

🟡 1 medium | 🔵 3 low

Findings

🟡 [MEDIUM] Workflow "llm-validation.yml" accesses secrets and has network egress. Verify secrets are not sent to external endpoints.

• Rule: WORKFLOW_SECRET_TO_UPLOAD_PATH
• File: .github/workflows/llm-validation.yml
• Recommendation: Audit this workflow for secret-to-network paths. Minimize secret scoping.

🔵 [LOW] Action "homeofe/supply-chain-guard@v5" uses a version tag instead of a commit SHA. Tags can be force-pushed to point to different commits.

• Rule: GHA_TAG_NOT_SHA
• File: .github/workflows/supply-chain-guard.yml:21
• Match: homeofe/supply-chain-guard@v5
• Recommendation: Consider pinning this action to a full commit SHA for maximum security. Tags can be moved to point to malicious code.

🔵 [LOW] Action "homeofe/supply-chain-guard@v5" is from third-party owner "homeofe". Third-party actions can be compromised.

• Rule: GHA_THIRD_PARTY_ACTION
• File: .github/workflows/supply-chain-guard.yml:21
• Match: homeofe/supply-chain-guard@v5
• Recommendation: Pin "homeofe/supply-chain-guard@v5" to a specific commit SHA and audit the action source code before use.

🔵 [LOW] Build workflow found but no signed provenance or attestation detected (SLSA Level 1). Artifacts cannot be cryptographically verified.

• Rule: SLSA_NO_PROVENANCE
• Recommendation: Add 'slsa-framework/slsa-github-generator' or 'actions/attest-build-provenance' to your release workflow to reach SLSA Level 2. Consider cosign for container signing.

Recommendations

• Review the listed findings and assess whether they represent legitimate functionality or potential threats.

---

Generated by supply-chain-guard