coderifts 4.11.0 → 5.0.0

package/CHANGELOG.md

@@ -1,5 +1,64 @@
 # Changelog
 
+## Unreleased
+
+### Fixed
+- **P0 — `setup-required-check --apply` no longer reports `APPLIED` over a
+  configuration `enforce --check` rejects.** The 4.12.0 round bound the required
+  check to an issuer only on the branch where branch protection **already
+  exists**. When the protection fetch returned 404 the CREATE branch built its
+  own payload — `{ strict: false, contexts: ["CodeRifts / contract-gate"] }`,
+  the issuer-less legacy array — and the read-back reported `APPLIED` with exit
+  0, while `enforce --check` graded the same repository
+  `legacy_contexts_no_issuer_binding`. Both branches now use one payload
+  builder, so the create write carries the same `checks[]` / `app_id` binding as
+  the update write.
+- **The read-back runs the enforcement verifier.** `APPLIED` previously meant
+  the context *name* appeared in `required_status_checks`, which is the grade
+  `enforce --check` refuses. It now means `evaluateRequiredCheck` — the same
+  function that grades enforcement — returned `VERIFIED`. `--json` gains
+  `verified_status`, `verified_reason_code` and, on failure,
+  `verified_reason`; an unverifiable apply exits 1 as `VERIFY_FAILED`.
+- **Repository rulesets are graded, not merely named.** `RULESET_REQUIRED` used
+  to be reported for any ruleset mentioning the check context. A ruleset with no
+  `integration_id` is satisfiable by any issuer, and one with
+  `enforcement: "evaluate"` is a dry run that reports without blocking; both
+  produced a green exit 0. They are now `NOT_VERIFIED`
+  (`ruleset_no_issuer_binding` / `ruleset_evaluate_mode`) and the command
+  proceeds to offer the classic-protection apply. `--json` gains
+  `ruleset_status`, `ruleset_reason_code` and `ruleset_names_by_name_only`.
+  Rulesets that could not be read are `UNVERIFIABLE`, never "none".
+
+### Changed
+- **BREAKING for adopters on the STRICT template — `require-grant: 'true'`.**
+  `coderifts init --agents --strict` now writes `require-grant: 'true'` for
+  contract-gate ≥0.5.0, so the merge gate BLOCKS unless every changed governed
+  path is covered by a valid `cr.exec.v1` execution grant. Before this, the
+  guard demanded a grant in strict mode and the strict workflow demanded
+  verified monitoring, while the gate that actually blocks let a grant-less
+  change through.
+
+  **What breaks:** a repository already using the strict template starts failing
+  any pull request that changes a governed contract path
+  (openapi/graphql/grpc/asyncapi/mcp-manifest) and carries no valid grant, with
+  `grant_not_supplied`. A pull request that changes no contract artifact is
+  unaffected — the gate short-circuits earlier as `no_contract_changes`. So the
+  affected set is not "some PRs": it is every PR this gate actually evaluates.
+
+  **What you must do:** publish a grant for the change set through the
+  `CODERIFTS_EXECUTION_GRANT` repository variable the template reads, or remove
+  the three `require-grant` / `execution-grant` / `grant-operation` lines from
+  your workflow. A `cr.exec.v1` grant binds `operation ∥ target_id ∥
+  after_payload`, and `after_payload` is the after-content of the changed
+  governed files — so a variable pinned once covers exactly one diff and fails
+  every other PR as `grant_does_not_cover_path`. Treat the variable as a
+  delivery slot to populate per change set, not a set-and-forget value.
+
+  Re-running `init` does not rewrite an existing workflow file, so this reaches
+  a repository only when the file is regenerated. The default (non-strict)
+  template is unchanged and stays non-blocking; it carries the same three lines
+  commented, with a note saying why the two differ.
+
 ## 4.10.0
 
 ### Added

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 CodeRifts
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.