chore(#3430): fix openspec validate warnings across boost specs#3431
chore(#3430): fix openspec validate warnings across boost specs#3431fullsend-ai-coder[bot] wants to merge 1 commit into
Conversation
Run `openspec validate --changes` and fix all 49 validation errors across 23 spec files in 5 change directories. Two categories of fixes: 1. Add RFC 2119 language (MUST/SHALL) to requirement descriptions under ADDED and MODIFIED delta sections. The validator requires requirement text to contain normative keywords. Affected 9 spec files with existing delta sections. 2. Add ADDED Requirements delta section to 14 spec files that only had EXISTING Requirements. The validator requires at least one delta section (ADDED/MODIFIED/REMOVED) in specs/ files. Added a minimal "Specification Coverage" requirement establishing the baseline. Also added missing requirement description text to 3 requirements in fine-grained-permissions/spec.md (Infrastructure Permissions, Permission Registration Best Practices, Functional Area Permissions). All 5 changes now pass: `openspec validate --changes` reports 5 passed, 0 failed. Closes #3430
fullsend-ai-coder
Bot
requested review from
a team,
durandom and
gabemontero
as code owners
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3431 +/- ##
=======================================
Coverage 53.55% 53.55%
=======================================
Files 2251 2251
Lines 85723 85723
Branches 24171 24171
=======================================
Hits 45908 45908
Misses 38296 38296
Partials 1519 1519
*This pull request uses carry forward flags. Click here to find out more. Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
|
🤖 Finished Review · ✅ Success · Started 12:09 PM UTC · Completed 12:20 PM UTC |
ReviewFindingsLow
Info
|
![fullsend-ai-review[bot]](https://avatars.githubusercontent.com/in/3478501?s=60&v=4){kind=small}
| ### Requirement: New Config Categories | ||
|
|
||
| New features require additional runtime configuration fields. | ||
| New features MUST have additional runtime configuration fields. |
There was a problem hiding this comment.
[low] internal consistency
The mechanical insertion of MUST changes the semantics of the requirement description. The original 'New features require additional runtime configuration fields' means 'the new features listed below need config fields.' The changed text 'New features MUST have additional runtime configuration fields' reads as a universal mandate that all new features must always include runtime config fields, which is broader than intended.
Suggested fix: Reword to preserve the original intent while using RFC 2119 language, e.g., 'The following new features MUST have runtime configuration fields as specified below.'
| ### Requirement: Tool Lifecycle Permissions (Resource-Based) | ||
|
|
||
| RBAC policies govern Kagenti tool lifecycle transitions. The `boost-tool` resource type represents Kagenti tools (K8s workloads with lifecycle governance) — not MCP servers or MCP tools. MCP servers are registered endpoints without lifecycle permissions; MCP tools are runtime-discovered children of MCP servers with no independent lifecycle. | ||
| RBAC policies MUST govern Kagenti tool lifecycle transitions. The `boost-tool` resource type represents Kagenti tools (K8s workloads with lifecycle governance) — not MCP servers or MCP tools. MCP servers are registered endpoints without lifecycle permissions; MCP tools are runtime-discovered children of MCP servers with no independent lifecycle. |
There was a problem hiding this comment.
[info] internal consistency
The requirement description for 'Tool Lifecycle Permissions' had RFC 2119 MUST added to only the first sentence. The remainder is definitional text establishing scope boundaries, which reasonably does not require RFC 2119 keywords.
| ### Requirement: Security Mode Naming | ||
|
|
||
| The development security mode uses an explicit name that communicates its purpose. The legacy name `none` is not accepted. | ||
| The development security mode MUST use an explicit name that communicates its purpose. The legacy name `none` SHALL NOT be accepted. |
There was a problem hiding this comment.
[info] internal consistency
The 'Security Mode Naming' requirement mixes MUST and SHALL NOT in the same description. Per RFC 2119 these are semantically equivalent, but stylistically inconsistent with the rest of the PR which exclusively uses MUST.
fullsend-ai-review
Bot
added
the
ready-for-merge
Run
openspec validate --changesand fix all 49 validation errors across 23 spec files in 5 change directories.Two categories of fixes:
Add RFC 2119 language (MUST/SHALL) to requirement descriptions
under ADDED and MODIFIED delta sections. The validator requires
requirement text to contain normative keywords. Affected 9 spec
files with existing delta sections.
Add ADDED Requirements delta section to 14 spec files that only
had EXISTING Requirements. The validator requires at least one
delta section (ADDED/MODIFIED/REMOVED) in specs/ files. Added a
minimal "Specification Coverage" requirement establishing the
baseline.
Also added missing requirement description text to 3 requirements in fine-grained-permissions/spec.md (Infrastructure Permissions, Permission Registration Best Practices, Functional Area Permissions).
All 5 changes now pass:
openspec validate --changesreports 5 passed, 0 failed.Closes #3430
Post-script verification
chore/boost-openspec-validate-3430)ff5b234442d685a6b2e28bc2b1137aa233132855..HEAD)