Define the release capability policy for operations (1.1.3)#5
Conversation
Add the pre-implementation ExecPlan for roadmap task 1.1.3 so the capability policy can be reviewed before code changes land. Record the approval gate, implementation milestones, validation gates, CodeRabbit expectations, and research inputs for the future feature work.
Pre-implementation ExecPlan for release capability policy (task 1.1.3)This pull request introduces a new ExecPlan document ( ExecPlan scope and constraintsThe ExecPlan establishes six key constraints grounded in existing architectural decisions:
The plan includes detailed tolerances (scope, file count, lines, dependencies, API stability) and risk mitigations addressing OpenAPI pin availability, policy–handler coupling, ambiguous operation classifications, and invariant validation strategy. Supporting infrastructure changesThe PR also delivers foundational work needed to execute the plan:
Validation and next stepsThe PR passed local validation gates (formatting, linting, tests, markdown checks). The ExecPlan is explicitly waiting for user approval before the execution phase begins; silence is not approval. The plan document guides implementers through staged execution: creating a pure capability policy registry, generating a capability matrix, wiring the unsupported response adapter, and updating documentation and roadmap records. Success is measured by every operation being classified exactly once, unsupported operations returning correct WalkthroughThe PR establishes automated management of the pinned DigitalOcean OpenAPI contract through a Bun refresh script with provenance tracking, whilst introducing comprehensive planning documentation for the release capability policy feature. The refresh script validates upstream responses, redacts secrets, and records source metadata; supporting docs guide developers through the refresh process and design implications. ChangesOpenAPI Artefact Pinning and Refresh Infrastructure
Release Capability Policy ExecPlan
Possibly related PRs
Suggested labels
Poem
Caution Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional.
❌ Failed checks (1 error, 3 warnings)
✅ Passed checks (14 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint skipped: no ESLint configuration detected in root package.json. To enable, add Comment |
|
@coderabbitai Please suggest a fix for this audit violation and supply a prompt for an AI coding agent to enable it to apply the fix. |
This comment was marked as resolved.
This comment was marked as resolved.
Force transitive `fast-uri` consumers onto 3.1.2 to remediate GHSA-v39h-62p7-jpjc / CVE-2026-6321 while preserving the existing direct production and development dependency declarations. Refresh `bun.lock` with `bun install` so the override is applied consistently across the dependency graph.
Check in the bundled DigitalOcean public API v2 OpenAPI contract with provenance that records the upstream source, commit, refresh command, response metadata, byte length, and SHA-256 hash. Add a Bun refresh script so future compatibility updates can reproduce the pin deliberately, and mark roadmap task 1.3.1 done.
557b879 to
30ff6ad
Compare
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Sorry @leynos, your pull request is larger than the review limit of 500000 diff characters
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/execplans/1-1-3-define-the-release-capability-policy-for-operations.md`:
- Line 82: Update each occurrence of the phrase "if implementation" to "if the
implementation" to improve grammar and clarity; specifically search for the
exact token sequence "if implementation" in the document (e.g., the instances at
the current mentions around lines where "File count: if implementation needs to
modify more than twelve tracked files" appears) and insert the definite article
"the" immediately before "implementation" in all such occurrences.
- Line 144: Replace all American spellings of "normalized" and "normalization"
with en-GB-oxendict spellings "normalised" and "normalisation" throughout the
document; specifically search for the tokens "normalized" and "normalization"
(including plural/inflected forms) and update them in each occurrence (notably
the instances flagged in the review), ensuring consistency and leaving
surrounding punctuation/formatting unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 6e555fcf-fb56-4833-93e0-c6b3051c8017
⛔ Files ignored due to path filters (1)
bun.lockis excluded by!**/*.lock
📒 Files selected for processing (9)
docs/developers-guide.mddocs/digitalpuddle-technical-design.mddocs/execplans/1-1-3-define-the-release-capability-policy-for-operations.mddocs/roadmap.mdpackage.jsonscripts/refresh-digitalocean-openapi.tssrc/openapi/README.mdsrc/openapi/digitalocean.openapi.provenance.jsonsrc/openapi/digitalocean.openapi.yaml
| - Scope: if implementation requires a broad source-layout migration beyond | ||
| `src/openapi`, narrowly needed route assembly seams, tests, and documentation, | ||
| stop and ask for approval. | ||
| - File count: if implementation needs to modify more than twelve tracked files |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial | 💤 Low value
Add definite articles before "implementation" for clarity.
Lines 82, 381, and 607 use "if implementation" as a mass noun. Add "the" before "implementation" to improve readability.
Triage: [type:grammar]
Proposed changes
Line 82:
-- Scope: if implementation requires a broad source-layout migration beyond
+- Scope: if the implementation requires a broad source-layout migration beyondLine 381:
-Keep this API small. If implementation needs more fields, document why in the
+Keep this API small. If the implementation needs more fields, document why in theLine 607:
-- A LemmaScript proof is added only if implementation introduces an axiom or
+- A LemmaScript proof is added only if the implementation introduces an axiom orAlso applies to: 381-381, 607-607
🧰 Tools
🪛 LanguageTool
[uncategorized] ~82-~82: Possible missing article found.
Context: ... and ask for approval. - File count: if implementation needs to modify more than twelve tracke...
(AI_HYDRA_LEO_MISSING_THE)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/execplans/1-1-3-define-the-release-capability-policy-for-operations.md`
at line 82, Update each occurrence of the phrase "if implementation" to "if the
implementation" to improve grammar and clarity; specifically search for the
exact token sequence "if implementation" in the document (e.g., the instances at
the current mentions around lines where "File count: if implementation needs to
modify more than twelve tracked files" appears) and insert the definite article
"the" immediately before "implementation" in all such occurrences.
| spec evolution. | ||
| Severity: medium. | ||
| Likelihood: medium. | ||
| Mitigation: key registry records by method and normalized path, treat |
There was a problem hiding this comment.
Change "normalized" to "normalised" throughout.
The document uses American spelling "normalized" and "normalization" in multiple locations. Change all instances to "normalised" and "normalisation" to comply with en-GB-oxendict spelling requirements.
Triage: [type:spelling]
Proposed corrections
Line 144:
- Mitigation: key registry records by method and normalized path, treat
+ Mitigation: key registry records by method and normalised path, treatLine 244:
- normalized OpenAPI path, with `operationId` as a lookup alias.
+ normalised OpenAPI path, with `operationId` as a lookup alias.Line 367:
-The module should accept normalized operation metadata rather than reading
+The module should accept normalised operation metadata rather than readingLine 387:
-- path normalization without losing OpenAPI path parameters;
+- path normalisation without losing OpenAPI path parameters;Line 593:
- exactly once by method and normalized path.
+ exactly once by method and normalised path.As per coding guidelines: "Use en-GB-oxendict (-ize / -yse / -our) spelling and grammar (examples: 'recognize,' 'synthesized,' 'polymerization,' 'analyse,' 'colour,' 'behaviour')." The word "normalise" takes the -ise suffix in this spelling system.
Also applies to: 244-244, 367-367, 387-387, 593-593
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/execplans/1-1-3-define-the-release-capability-policy-for-operations.md`
at line 144, Replace all American spellings of "normalized" and "normalization"
with en-GB-oxendict spellings "normalised" and "normalisation" throughout the
document; specifically search for the tokens "normalized" and "normalization"
(including plural/inflected forms) and update them in each occurrence (notably
the instances flagged in the review), ensuring consistency and leaving
surrounding punctuation/formatting unchanged.
1 participant
Summary
This branch adds the pre-implementation ExecPlan for roadmap task (1.1.3), defining how the release capability policy for
scriptable,engine-backed,stubbed, andunsupportedoperations should be implemented after approval. It exists to let reviewers approve the policy shape before runtime code changes land.Roadmap task: (1.1.3)
ExecPlan: docs/execplans/1-1-3-define-the-release-capability-policy-for-operations.md
Review walkthrough
Validation
bun fmt: passed.make generate: passed; regenerated inherited GraphQL resolver types needed by the current test suite.make check-fmt: passed.make lint: passed.env -u FORCE_COLOR make test: passed, 113 tests, 0 failures, 2 snapshots.make markdownlint: passed.coderabbit review --agent: run three times. Valid prose findings were addressed; remaining automated-isespelling suggestions were left unapplied because this repository uses en-GB-oxendict-izeforms.Notes
This is a draft pre-implementation pull request. It does not mark roadmap task (1.1.3) as done because the roadmap success criteria require generated docs and
501 Not Implementedbehaviour to be implemented after the plan is approved.