fix(opencode): distinguish prompt defense scopes

[Kerberosmansour (kerberosmansour)]

Summary

• report prompt-defense coverage for both effective context and operator-configured additional context
• add explicit scope metadata so consumers cannot confuse the two measurements
• show both grades in the OpenCode session initialization log
• preserve the existing effective-context status fields for compatibility

Root cause

The previous grade measured the fully compiled context, which includes bundled guardrails, but its name made it easy to interpret as a grade of operator-supplied policy content.

Validation

• cd agent-governance-opencode && npm run check — 26/26 tests passed
• changed-line spelling and whitespace checks passed

Closes #3664

Tracking and related work

• Primary issue: [Bug]: promptDefenseGrade does not reflect operator configuration #3664; the closure directive above remains authoritative.
• Related session-scoped state work in [Feature]: expose session-scoped state and staged evaluation in OpenCode #3669 is intentionally not implemented here.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[github-actions]

PR Review Summary

Check	Status	Details
🔍 Code Review	⚠️ Missing	No current-run comment
🛡️ Security Scan	⚠️ Missing	No current-run comment
🔄 Breaking Changes	⚠️ Missing	No current-run comment
📝 Docs Sync	⚠️ Missing	No current-run comment
🧪 Test Coverage	⚠️ Missing	No current-run comment

Verdict: ⚠️ AI review incomplete; ready for human review

AI review comments are untrusted advisory output. The summary reports workflow-generated completion status only, not model-authored pass/fail claims.

[github-actions]

🟡 Contributor Check: MEDIUM

Check	Result
Profile	MEDIUM
Credential	MEDIUM
Overall	MEDIUM

Automated check by AGT Contributor Check.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Imran Siddique (imran-siddique)]

This is a metric-honesty fix, and for a governance toolkit that is a category worth taking as seriously as a control fix. A number that flatters is worse than no number, because it terminates the operator's investigation.

The specific confusion is the one that matters: a grade computed over the fully compiled context, which already includes bundled guardrails, reads as a grade of what the operator wrote. Someone tuning additionalContext sees a good letter and stops. Reporting both, with effective-context and operator-additional-context named explicitly in the payload rather than implied by field naming, is the right shape. Keeping the existing fields untouched so consumers do not break is the right call for a change whose whole point is that a field name misled people.

One question rather than a change request, and it is for the maintainers as much as you.

promptDefenseBlockingScope: "effective-context" is an honest label, and what it documents is that minimumPromptDefenseGrade still gates on the compiled context. So an operator who sets a minimum grade intending to hold their own context to a standard is still being gated on the measurement that includes the bundled defaults. Their configured content could be empty and the gate would pass on the strength of guardrails they did not write.

Not changing enforcement inside a reporting PR is the conservative call and I agree with it. But the gap now exists in a field name and nowhere else, and field names are not a backlog. MohammadHaroonAbuomar liamcrumm worth deciding whether minimumPromptDefenseGrade should key on the configured scope, or whether a second threshold is the answer. If neither, the docs should say which scope the gate measures, because the two-scope split makes the question obvious to the next reader.

No approve bit on this repo, so a comment, but I would merge it as it stands.