@sleepy_panda_srl/portulan 0.1.2 → 0.1.3

package/cli/version-carriers.mjs

@@ -70,6 +70,19 @@ export const MUST_CARRY = ["README.md", "SECURITY.md", ".portulan/products/portu
 // The record layer. These files preserve sentences that are no longer true, on purpose.
 export const RECORD_PREFIXES = [
     "CHANGELOG.md",
+    // **A release record is record-layer by nature**, and it was classified here deliberately rather
+    // than left to whether a pattern happens to match one. `evals/releases/<version>.md` is generated
+    // per release and preserves that release's conditions forever — so the moment `0.1.4` exists,
+    // `0.1.3`'s register is a document stating, correctly and permanently, facts about a version that
+    // is no longer current. That is precisely what this exclusion is for. Its own drift is held by the
+    // `release-eval` recipe, which byte-compares each register against the capture it was rendered
+    // from — so for `<version>.json` and `<version>.md` this moves coverage to the rail that can
+    // actually read them rather than removing it. **`evals/releases/README.md` is the exception and is
+    // named rather than glossed:** `release-eval` reads only the two version-keyed files, so that
+    // README now sits under an excluded prefix with nothing covering it. Harmless today — it states no
+    // current version — and it is exactly this module's own third named residual, a live claim under an
+    // excluded prefix, so it is recorded here instead of being discovered by the next reader.
+    "evals/releases/",
     "docs/plan.md",
     "docs/milestones/",
     ".portulan/handoffs/",

package/core/templates/gate-policy.md

@@ -26,15 +26,15 @@
 
 ```json
 {
-  "portulan": { "gates": "1.0" },
+  "portulan": { "spec": "2.2" },
 
   "why": "{Why this team gates what it gates — the sentence a new agent reads first. Name the blast radius you are protecting, not the tools you are restricting.}",
 
   "floor": {
     "branch": "{default branch}",
-    "require_pull_request": true,
-    "block_force_push": true,
-    "checks": []
+    "checks": [],
+    "reviews": 0,
+    "resolve_conversations": true
   },
 
   "rules": [
@@ -45,11 +45,17 @@
       "reason": "{Why, and what to do instead. Prohibited means no yes makes this acceptable — if a human could approve it, it is Gated, not Prohibited.}"
     },
     {
-      "id": "{rule-id}",
+      "id": "force-push-without-a-lease",
       "tier": "gated",
-      "action": { "shell": "{command prefix}" },
+      "action": { "shell": "git push --force" },
       "reason": "{Why a human must approve each time. Prefer the undoability test: what does it cost if this was wrong and nobody noticed for a week?}"
     },
+    {
+      "id": "delete-a-ref",
+      "tier": "gated",
+      "action": { "shell": "git push --delete" },
+      "reason": "{Why a deletion waits for a person. These two ids and actions are filled in already — they are the two destructive ref spellings the floor backend can express, and a `floor` block with no rule reaching it refuses to compile.}"
+    },
     {
       "id": "{rule-id}",
       "tier": "propose",
@@ -60,6 +66,16 @@
 }
 ```
 
+> **`floor` is exactly four keys, and they are the four `compile` reads** — `branch`, `checks`,
+> `reviews`, `resolve_conversations`. It is not a free-form block: `reviews` is a non-negative integer
+> and `resolve_conversations` a boolean, both required, because a floor that omitted them would export
+> one weaker than the one already in force. _(Until 2026-08-22 this skeleton emitted
+> `require_pull_request` and `block_force_push` instead — two keys no version of the compiler has ever
+> read — beside a `portulan.gates` version key it does not read either. A scaffold the next documented
+> step refuses is the defect this template's own closing paragraph warns about, one layer up;
+> [#329](https://github.com/sleepy-panda-srl/portulan/issues/329) reported it, and `new`'s test now
+> scaffolds this file and compiles it rather than only checking that it was written.)_
+>
 > **`checks: []` is deliberate and you should probably leave it that way at first.** A floor requiring a
 > status check that no workflow job reports is a red nobody caused — a fresh repository reports no checks,
 > and a real one reports something else, so any name guessed here fails on the first run. Add the check
@@ -72,5 +88,8 @@
 > print every rule against both rather than reasoning about it — the refusals are printed, never silent.
 >
 > **Start with the rules that destroy rather than create.** A ref deletion and a force-push are the two
-> the floor backend can express, they are the two whose damage is hardest to undo, and they are a policy's
-> honest first pair.
+> **destructive ref spellings** the floor backend can express — it also emits `pull_request` and
+> `required_status_checks` for a `propose` rule once `floor.checks` is non-empty, which is the paragraph
+> above — and they are the two whose damage is hardest to undo, so they are a policy's
+> honest first pair — so the skeleton above ships them filled in rather than as placeholders, which is
+> also what keeps the `floor` block reachable. Their `reason` is still yours to write.