From 05d1b4a7062ba0bdd87baa6b36df6a5095575dc1 Mon Sep 17 00:00:00 2001 From: Anders Alm Date: Wed, 30 Sep 2026 16:56:20 -0500 Subject: [PATCH 1/5] docs: weekly releases, develop line and merge on green AGENTS.md: develop is the integration line and main changes only through the weekly release PR. Weekly releases 0.7.N have a milestone fixed the Wednesday before, a Tuesday candidate, and three human checks before the tag (Sasha's visible review, Irzhy's release approval, Anders's ten-minute journey). Task PRs merge on green checks plus one independent agent review; irzhywau reviews signing, update, Inbox, keys, isolation, seed and CI or release PRs. Review has at most two rounds. Installed proofs use the CI install jobs when they cover the journey. The branching skill and Cursor rule drop the upstream/XX-dev procedure. CI runs on every push to develop. The Home entropy check follows the new branch roles. --- .claude/skills/branching-strategy/SKILL.md | 45 +++-------- .cursor/rules/branching-strategy.mdc | 10 +-- AGENTS.md | 90 ++++++++++++---------- scripts/home-entropy-check.mjs | 7 +- 4 files changed, 68 insertions(+), 84 deletions(-) diff --git a/.claude/skills/branching-strategy/SKILL.md b/.claude/skills/branching-strategy/SKILL.md index 38c74190b..7e2dcfdac 100644 --- a/.claude/skills/branching-strategy/SKILL.md +++ b/.claude/skills/branching-strategy/SKILL.md @@ -5,49 +5,24 @@ description: Use when creating a new branch or git worktree for a feature, bugfi # Branching Strategy -## Overview - -New work branches start from a user-selected `upstream/XX-dev` integration branch. The current checkout and `main` are not implicit bases. Resolve available lines from fetched refs; the user chooses the base. - -`main` is the release line. `upstream/XX-dev` branches are the versioned dev/integration lines where feature and bugfix work lands. +`develop` is the integration line. Task branches start from `develop` and merge back into it. `main` is the release line and changes only through the weekly release PR. The owning issue may name another base. ## Workflow -1. **Refresh and discover bases.** Remote-tracking refs go stale here; fetch first: +1. Fetch first, because remote-tracking refs go stale: ```bash git fetch origin --prune - git branch -a --list '*upstream/*' # upstream/XX-dev lines - git branch -a --list '*feat/*' --list '*fix/*' # active working branches ``` - If remote state is in doubt, cross-check with `gh api repos///branches --jq '.[].name'`. - -2. **Ask the user which base to start from** (AskUserQuestion). Always ask, even when only one `upstream/XX-dev` exists. Offer as choices: - - Each `upstream/XX-dev` branch — recommend the newest version. - - "An existing working branch" — for work that depends on another in-flight branch. - -3. **Create the branch** (name it `feat/` or `fix/`, matching existing repo conventions): +2. Use the base the owning issue names; otherwise use `origin/develop`. +3. Create the branch as `feat/` or `fix/`: ```bash - git checkout -b fix/ - # or isolated: - git worktree add ../- -b feat/ + git worktree add ../- -b feat/ origin/develop ``` - -4. **Dependent base? Flag the merge-back immediately.** If the base is a working branch rather than `upstream/XX-dev`, tell the user in your response, and repeat it when the work is ready to merge: - > ⚠️ This branch is based on ``, not `upstream/XX-dev`. It must merge back only after (or together with) its parent, and merging into `upstream/XX-dev` may conflict with the parent's changes. Rebase onto the parent if it moves. - -5. Don't push or set an upstream tracking branch until the user asks. - -## Quick Reference - -| Situation | Base | Extra step | -|---|---|---| -| Feature / bugfix | `upstream/XX-dev` chosen by user | — | -| Work depending on an in-flight branch | that working branch, if user confirms | Merge-back conflict warning (step 4) | -| Base unclear / user unavailable | stop and ask | Never guess | +4. If the base is another in-flight branch, say so in the PR: the branch merges after its parent and needs a rebase if the parent moves. +5. Pushes follow the Push Approval Levels in `AGENTS.md`. ## Common Mistakes -- **Branching from current HEAD or `main` without asking** — the checked-out branch is not evidence of the right base. List the `upstream/*-dev` lines and ask. -- **"Only one dev branch exists, so no need to ask"** — still ask; the user may want a dependent working branch as base, or a new dev line may be pending. -- **Silent dependent branch** — creating a branch off another feature branch without stating the merge-back risk leaves the user to discover conflicts at PR time. -- **Trusting stale remote refs** — always `git fetch origin --prune` before listing candidate bases. +- Branching from the current checkout or from `main`. The checked-out branch is not evidence of the right base. +- Trusting stale remote refs. Fetch before branching. +- A silent dependent branch. State the parent in the PR so the merge order is clear. diff --git a/.cursor/rules/branching-strategy.mdc b/.cursor/rules/branching-strategy.mdc index 75ab59a05..ad7653a99 100644 --- a/.cursor/rules/branching-strategy.mdc +++ b/.cursor/rules/branching-strategy.mdc @@ -6,12 +6,10 @@ alwaysApply: false # Branching Strategy -New work branches start from an `upstream/XX-dev` integration branch (e.g. `upstream/0.6-dev`) — never silently from `main` or from whatever branch is checked out. The user chooses the base; never pick it yourself. +Task branches start from `develop` (or the base the owning issue names) and merge back into it. `main` changes only through the weekly release PR. -1. `git fetch origin --prune`, then list `upstream/*-dev` lines and active `feat/*`/`fix/*` branches. -2. Ask the user which base to start from, offering each `upstream/XX-dev` (newest recommended) plus "an existing working branch" for work that depends on another in-flight branch. Ask even when only one dev line exists. -3. Create the branch as `feat/` or `fix/` from the chosen base. -4. If the base is a working branch rather than `upstream/XX-dev`, warn immediately: it must merge back only after (or together with) its parent, merging into `upstream/XX-dev` may conflict with the parent's changes, and it needs a rebase if the parent moves. Repeat the warning at merge time. -5. Do not push or set upstream tracking until asked. +1. `git fetch origin --prune`. +2. Create the branch as `feat/` or `fix/` from `origin/develop` or the issue's base. +3. If the base is another in-flight branch, say so in the PR; it merges after its parent. Canonical workflow: @.claude/skills/branching-strategy/SKILL.md diff --git a/AGENTS.md b/AGENTS.md index 4b8be546f..4b88ccbb9 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -7,8 +7,9 @@ are the only place for work status, acceptance criteria and proof. ## Work Tracking And Acceptance - GitHub issues own the work queue. In each lane, take the lowest-numbered open - task whose dependencies are satisfied and which has no active blocker. Keep - at most one task issue In progress per lane. Parent issues group the lane; + task in the current weekly milestone whose dependencies are satisfied and + which has no active blocker. Keep at most one task issue In progress per + lane. Parent issues group the lane; they do not authorize a second active task. User messages approve, redirect or reorder work; they do not create a parallel task list. - Close a task only when its Done means is proven and its PR has the required @@ -58,10 +59,9 @@ are the only place for work status, acceptance criteria and proof. ## Branch Roles -- `main` is the stable source line. -- `upstream/-dev` branches are development integration lines. The - owning GitHub issue records the approved task base; fetched refs verify it. - This replaces the old rule to choose the active line from `state.md` and fetched refs. +- `main` is the release line. It changes only through the weekly release PR. +- `develop` is the integration line. Task PRs merge into it when their checks + and reviews pass (see Review And Commit Discipline). - Feature and fix branches remain unpublished working lines until they are explicitly pushed for review. - Do not assume a `review/*` or `live` ref exists. Identify the exact public @@ -75,33 +75,33 @@ are the only place for work status, acceptance criteria and proof. ## Creating Work Branches -Every 0.7.1 task branch uses [feat/0.7.1-models](https://github.com/Elacity/elastos-runtime/tree/feat/0.7.1-models) as its base and PR target unless -the owning issue specifies another base. This is standing approval; do not ask -for each task. Fetch the current base before branching and record it in the issue. -Tasks that use this default base depend on the models branch and merge back into -it. Exceptions follow the base and target recorded in their issue. If the base -moves, check compatibility before merging; history rewrite still needs approval. -This standing approval takes precedence over the branching skill's per-task -base question for 0.7.1. - -For other work without an approved issue base, use a user-selected -`upstream/XX-dev` integration branch. The current checkout and `main` are not -implicit bases: - -- Run `git fetch origin --prune`, then list `upstream/*-dev` lines and active - `feat/*`/`fix/*` branches before proposing bases. -- Ask the user which base to start from, offering each `upstream/XX-dev` - (newest recommended) plus "an existing working branch" for work that depends - on another in-flight branch. Ask even when only one dev line exists. -- If the chosen base is a working branch rather than `upstream/XX-dev`, warn - immediately: the new branch must merge back only after (or together with) - its parent, merging it into `upstream/XX-dev` may conflict with the parent's - changes, and it needs a rebase if the parent moves. -- Name branches `feat/` or `fix/`. Pushes and upstream tracking - follow the Push Approval Levels below. +Every task branch uses [develop](https://github.com/Elacity/elastos-runtime/tree/develop) +as its base and PR target unless the owning issue names another base. This is +standing approval; do not ask for each task. Fetch the current base before +branching. If the base moves, check compatibility before merging; history +rewrite still needs approval. A branch that depends on another in-flight branch +says so in its PR and merges after its parent. Name branches `feat/` or +`fix/`. Pushes and upstream tracking follow the Push Approval Levels below. Canonical workflow: [.claude/skills/branching-strategy/SKILL.md](.claude/skills/branching-strategy/SKILL.md). +## Weekly Releases + +- Each weekly release has a milestone `0.7.N`. Its scope is fixed on the + Wednesday before the release; work that misses it moves to the next milestone. +- On Tuesday the candidate is cut from `develop` as `release/0.7.N` with the + version bump and changelog, and opened as a PR to `main`. +- Three people confirm the candidate before the tag. Sasha reviews the visible + changes (CI screenshots and a short look) on his Wednesday. `irzhywau` + approves the release PR. Anders runs the ten-minute journey on his Mac: + update from the previous weekly release or a fresh install, sign in, one local + AI reply, one chat message and one Browser page. A failed journey or a visible + regression holds the tag for that week. +- On Wednesday the PR merges, `v0.7.N` is tagged on the merge commit, and `main` + merges back into `develop`. +- 0.8.0 is the weekly release in which every result in the 0.8.0 milestone meets + its Done means. + ## Branch Lifecycle Retire a branch or close a PR only with its owner's agreement. A green check, @@ -210,12 +210,10 @@ target before acting. - **No approval needed:** fast-forward pushes to the branch of the active task or its existing draft PR; opening draft PRs; rerunning checks; reading logs. Report what was pushed, including the remote, branch, commits and check results. -- **Standing task-merge permission:** merge a task PR only into the repository - and target branch explicitly approved by the user for that task. - Check that approval before merging. A change to the approved target requires - explicit user approval. The current candidate must pass all required checks, - independent review must be complete, required human reviews must approve the - candidate, all findings must be resolved, and its dependencies must be integrated. +- **Standing task-merge permission:** merge a task PR into `develop`, or into + the base its issue names, when all required checks pass, one independent agent + review has passed with its findings resolved, every required human review in + Review And Commit Discipline approves, and its dependencies are integrated. Check compatibility with the current base and report the PR, source and merge commits, review and checks. Use a normal merge; history rewrite needs approval. - **Standing test-key permission:** create and use disposable keys and signatures @@ -251,10 +249,16 @@ capsules, provider config, and `components.json`. - Keep review requests off draft PRs. When a PR leaves draft, request the required reviewers on GitHub yourself and name them in the report. Keep an existing request instead of sending a duplicate. -- For a PR authored by Anders that touches signing, update checks, Inbox - approvals, keys, sandboxing or seed publishing, name `irzhywau` as a required - human reviewer. Also name the feature owner when the task requires that review. - Independent agent review and required human review are separate evidence. +- `irzhywau` is a required human reviewer for a PR that touches signing, update + checks, Inbox approvals, keys, sandboxing or isolation, seed publishing, or CI + and release workflows, and for each weekly release PR. When `irzhywau` is the + author, Anders reviews. Also name the feature owner when the task requires + that review. Other task PRs merge on green checks and one independent agent + review. Independent agent review and required human review are separate + evidence. +- Review has at most two rounds. After two rounds, or after the same failure + twice, fix the product cause or escalate: review questions go to `irzhywau`, + scope questions to Anders. Ask before building new diagnostic tooling. - Keep commits authority-bound and reviewable: one coherent concern per commit, with its own verification commands. - Preserve commit history by default. Ask before amending, squashing, rebasing @@ -312,6 +316,12 @@ path, installed artifact path, SHA-256 of the built and installed artifact, restart or stale-process cleanup performed, and the live localhost proof command and result. +Prove installed behavior on the CI install jobs (GitHub-hosted Linux x86-64, +Linux ARM64 and macOS machines) when they cover the journey, and link that CI +run as the proof. Otherwise use the installed-proof steps above. The Jetson is +checked on the weekly candidate. A PR that changes what users see links the CI +screenshots at desktop and phone width. + ## Journey Register Gate Use [docs/audits/ElastOS-Home-Journey-Audit.xlsx](docs/audits/ElastOS-Home-Journey-Audit.xlsx) diff --git a/scripts/home-entropy-check.mjs b/scripts/home-entropy-check.mjs index f22d99524..c26b67fc3 100755 --- a/scripts/home-entropy-check.mjs +++ b/scripts/home-entropy-check.mjs @@ -1853,9 +1853,10 @@ assert( agentsContract.includes("## Public Live Deployment") && agentsContract.includes("## Staging Machines") && agentsContract.includes("## Browser Claim Discipline") && - agentsContract.includes("`main` is the stable source line") && - agentsContract.includes("`upstream/-dev` branches are development integration lines") && - includesNormalized(agentsContract, "the active line from `state.md` and fetched refs") && + agentsContract.includes("## Weekly Releases") && + agentsContract.includes("`main` is the release line") && + agentsContract.includes("`develop` is the integration line") && + includesNormalized(agentsContract, "Fetch the current base before branching") && agentsContract.includes("Do not assume a `review/*` or `live` ref exists") && agentsContract.includes("reporting its exact branch, commit, tree id, dirty status") && agentsContract.includes("Target proof must cite the exact source tree") && From a2865f816d3aec9bd2ee448c4a5ba9033f8761f3 Mon Sep 17 00:00:00 2001 From: Anders Alm Date: Wed, 30 Sep 2026 17:39:33 -0500 Subject: [PATCH 2/5] docs: fresh-install journey until updates land; one branching source The weekly ten-minute journey starts from a fresh install until UP-01 to UP-03 are merged. The branching skill and Cursor rule point to AGENTS.md instead of repeating its rules. --- .claude/skills/branching-strategy/SKILL.md | 24 +++++----------------- .cursor/rules/branching-strategy.mdc | 8 +------- AGENTS.md | 9 ++++---- 3 files changed, 11 insertions(+), 30 deletions(-) diff --git a/.claude/skills/branching-strategy/SKILL.md b/.claude/skills/branching-strategy/SKILL.md index 7e2dcfdac..b65703358 100644 --- a/.claude/skills/branching-strategy/SKILL.md +++ b/.claude/skills/branching-strategy/SKILL.md @@ -5,24 +5,10 @@ description: Use when creating a new branch or git worktree for a feature, bugfi # Branching Strategy -`develop` is the integration line. Task branches start from `develop` and merge back into it. `main` is the release line and changes only through the weekly release PR. The owning issue may name another base. +Follow **Creating Work Branches** and **Branch Roles** in the root `AGENTS.md`. They are the only source for bases, branch names and merge targets. -## Workflow +The usual case after `git fetch origin --prune`: -1. Fetch first, because remote-tracking refs go stale: - ```bash - git fetch origin --prune - ``` -2. Use the base the owning issue names; otherwise use `origin/develop`. -3. Create the branch as `feat/` or `fix/`: - ```bash - git worktree add ../- -b feat/ origin/develop - ``` -4. If the base is another in-flight branch, say so in the PR: the branch merges after its parent and needs a rebase if the parent moves. -5. Pushes follow the Push Approval Levels in `AGENTS.md`. - -## Common Mistakes - -- Branching from the current checkout or from `main`. The checked-out branch is not evidence of the right base. -- Trusting stale remote refs. Fetch before branching. -- A silent dependent branch. State the parent in the PR so the merge order is clear. +```bash +git worktree add ../- -b feat/ origin/develop +``` diff --git a/.cursor/rules/branching-strategy.mdc b/.cursor/rules/branching-strategy.mdc index ad7653a99..b702828a0 100644 --- a/.cursor/rules/branching-strategy.mdc +++ b/.cursor/rules/branching-strategy.mdc @@ -6,10 +6,4 @@ alwaysApply: false # Branching Strategy -Task branches start from `develop` (or the base the owning issue names) and merge back into it. `main` changes only through the weekly release PR. - -1. `git fetch origin --prune`. -2. Create the branch as `feat/` or `fix/` from `origin/develop` or the issue's base. -3. If the base is another in-flight branch, say so in the PR; it merges after its parent. - -Canonical workflow: @.claude/skills/branching-strategy/SKILL.md +Follow **Creating Work Branches** and **Branch Roles** in @AGENTS.md. They are the only source for bases, branch names and merge targets. diff --git a/AGENTS.md b/AGENTS.md index 4b88ccbb9..7f84cfb13 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -93,10 +93,11 @@ Canonical workflow: [.claude/skills/branching-strategy/SKILL.md](.claude/skills/ version bump and changelog, and opened as a PR to `main`. - Three people confirm the candidate before the tag. Sasha reviews the visible changes (CI screenshots and a short look) on his Wednesday. `irzhywau` - approves the release PR. Anders runs the ten-minute journey on his Mac: - update from the previous weekly release or a fresh install, sign in, one local - AI reply, one chat message and one Browser page. A failed journey or a visible - regression holds the tag for that week. + approves the release PR. Anders runs the ten-minute journey on his Mac: a + fresh install (an update from the previous weekly release once the signed + update tasks UP-01 to UP-03 are merged), sign in, one local AI reply, one chat + message and one Browser page. A failed journey or a visible regression holds + the tag for that week. - On Wednesday the PR merges, `v0.7.N` is tagged on the merge commit, and `main` merges back into `develop`. - 0.8.0 is the weekly release in which every result in the 0.8.0 milestone meets From 10b0a530fd28ce0ec9297f55d6b92a6ccc326eb8 Mon Sep 17 00:00:00 2001 From: Anders Alm Date: Fri, 2 Oct 2026 15:48:52 -0500 Subject: [PATCH 3/5] docs: follow started CI and link routine status evidence --- AGENTS.md | 66 ++++++++++++++++++++-------------- scripts/home-entropy-check.mjs | 12 +++++-- 2 files changed, 49 insertions(+), 29 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 7f84cfb13..60e8db116 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -16,16 +16,19 @@ are the only place for work status, acceptance criteria and proof. reviews and is merged. Until then, keep verified work open in QA / Review. Take the next unblocked task in that lane; starting it does not complete its predecessor. Keep blocked work open with its blocker in the issue. -- While CI runs after a push, start or continue the next eligible issue in the - other lane. Keep the one-active-task limit in each lane. Read CI results when - they finish; do not watch or poll CI. If both lanes are blocked, record the - blockers in their issues. +- Follow CI and installed journeys that you start to completion in the same + turn. While they run, continue eligible work in the other lane and keep the + one-active-task limit. Inspect the completed result, repair failures, and + verify the new candidate before handing back. An external blocker belongs + in the owning issue. - Run at most one heavy local build on this Mac at a time. Workers agree which issue owns that build before starting it. CI builds do not count toward this local limit. Continue reviews, source work or other light checks in parallel. -- Update the owning GitHub issue before reporting progress. State what changed, - link the PR, and record the exact candidate, checks, results and remaining - work. The report names the issue, PR, proof and next issue. +- Update the owning GitHub issue before reporting a state change. Routine + status notes and check-ins link the PR, CI run and review, then state the + result and remaining work. Keep exact source, tree and artifact identities + in installed-binary and release receipts, and in the private lifecycle + inventory. A routine status note uses those links instead of copied hashes. - Keep one work record. Do not create briefings, plans, gists or notes files. Existing `state.md`, `TASKS.md` and dated audits are historical references; move useful open work to its issue instead of maintaining a parallel queue. @@ -67,9 +70,10 @@ are the only place for work status, acceptance criteria and proof. - Do not assume a `review/*` or `live` ref exists. Identify the exact public review or deployed commit from fetched refs and target-host evidence before making either claim. -- Treat any other local branch or target-host checkout as evidence only after - reporting its exact branch, commit, tree id, dirty status, and verification - command. +- Verify the exact branch, commit, tree id, dirty status and command before + treating a local branch or target-host checkout as evidence. Keep these + identities in the lifecycle inventory or the installed-artifact receipt; + routine check-ins link the related PR, CI run and review. - Always report remote divergence. A local branch being green is not the same as `elacity/` being up to date. @@ -211,12 +215,12 @@ target before acting. - **No approval needed:** fast-forward pushes to the branch of the active task or its existing draft PR; opening draft PRs; rerunning checks; reading logs. Report what was pushed, including the remote, branch, commits and check results. -- **Standing task-merge permission:** merge a task PR into `develop`, or into - the base its issue names, when all required checks pass, one independent agent - review has passed with its findings resolved, every required human review in - Review And Commit Discipline approves, and its dependencies are integrated. - Check compatibility with the current base and report the PR, source and merge - commits, review and checks. Use a normal merge; history rewrite needs approval. +- **Standing task-merge permission:** merge your task PR into `develop`, or + into the user-approved base named in its issue, when all current checks pass, + the independent reviews below pass, findings are resolved, dependencies are + integrated, and any explicit human acceptance gate passes. Check current-base + compatibility and report links to the merged PR, CI run and reviews. Use a + normal merge; history rewrite needs approval. - **Standing test-key permission:** create and use disposable keys and signatures for a named, isolated test fixture. Keep its trust store separate from real Homes and production keys. Record its owner and cleanup condition; keep private @@ -226,7 +230,10 @@ target before acting. keys; changes on the seed or existing installed Homes; deleting branches; other secrets and credentials. -Signing runs outside CI. Fork PRs and publication jobs use GitHub-hosted runners. +The operator runs production signing with Anders's approval. Named isolated +fixtures may generate disposable keys and signatures in CI; their trust stays +separate from real Homes and production keys. Fork PRs and publication jobs use +GitHub-hosted runners. These levels replace blanket push-approval requirements. Verification and the agreed publication scope still apply. Keep unrelated work and private operational @@ -250,16 +257,21 @@ capsules, provider config, and `components.json`. - Keep review requests off draft PRs. When a PR leaves draft, request the required reviewers on GitHub yourself and name them in the report. Keep an existing request instead of sending a duplicate. -- `irzhywau` is a required human reviewer for a PR that touches signing, update - checks, Inbox approvals, keys, sandboxing or isolation, seed publishing, or CI - and release workflows, and for each weekly release PR. When `irzhywau` is the - author, Anders reviews. Also name the feature owner when the task requires - that review. Other task PRs merge on green checks and one independent agent - review. Independent agent review and required human review are separate - evidence. -- Review has at most two rounds. After two rounds, or after the same failure - twice, fix the product cause or escalate: review questions go to `irzhywau`, - scope questions to Anders. Ask before building new diagnostic tooling. +- Each task change needs one independent development review marked PASS. + Security code, including gateway, auth, provider launchers, confinement, + signing, publish/update, install.sh and workflows, also needs a posted + `Independent adversarial review ... VERDICT: PASS` from a different model + family than its author. Codex authors run `elastos-pr-review ` themselves + and verify that the posted verdict covers the current candidate. +- Agents merge their own task PRs after the current checks and reviews pass. + Keep explicit human acceptance gates recorded in the owning issue. Request + `irzhywau` for security follow-up: he reviews merged security task PRs, and a + finding goes into an existing issue or a revert when it reopens a hole. + Weekly release PRs still need his approval before merge and tag; when he is + the author, Anders reviews. Also request the feature owner when required. +- Use one development review round per coherent change. Resolve findings in + that round and fix their cause before requesting the current verdict. Scope + decisions belong to Anders. Ask before adding new diagnostic tooling. - Keep commits authority-bound and reviewable: one coherent concern per commit, with its own verification commands. - Preserve commit history by default. Ask before amending, squashing, rebasing diff --git a/scripts/home-entropy-check.mjs b/scripts/home-entropy-check.mjs index c26b67fc3..b972d6acc 100755 --- a/scripts/home-entropy-check.mjs +++ b/scripts/home-entropy-check.mjs @@ -1858,10 +1858,18 @@ assert( agentsContract.includes("`develop` is the integration line") && includesNormalized(agentsContract, "Fetch the current base before branching") && agentsContract.includes("Do not assume a `review/*` or `live` ref exists") && - agentsContract.includes("reporting its exact branch, commit, tree id, dirty status") && + includesNormalized(agentsContract, "Verify the exact branch, commit, tree id, dirty status and command") && agentsContract.includes("Target proof must cite the exact source tree") && agentsContract.includes("explicit user approval before the mutation") && - agentsContract.includes("WebRTC remote display"), + agentsContract.includes("WebRTC remote display") && + includesNormalized(agentsContract, "Follow CI and installed journeys that you start to completion in the same turn") && + includesNormalized(agentsContract, "status notes and check-ins link the PR, CI run and review") && + includesNormalized(agentsContract, "Keep exact source, tree and artifact identities in installed-binary and release receipts") && + includesNormalized(agentsContract, "Before deleting a duplicate ref, prove exact commit identity") && + includesNormalized(agentsContract, "Before deleting a worktree, verify its status, untracked files, open files/processes, and protecting ref") && + agentsContract.includes("VERDICT: PASS") && + agentsContract.includes("different model") && + agentsContract.includes("elastos-pr-review "), "Root AGENTS.md must preserve standing branch roles, fetched-base selection, target proof, public-live approval and Browser claim discipline", ); assert( From fb3b30bb15f247104344e1530c8ffeed82ffd0a0 Mon Sep 17 00:00:00 2001 From: Anders Alm Date: Fri, 2 Oct 2026 15:50:16 -0500 Subject: [PATCH 4/5] test(policy): refuse weakened review and release gates --- scripts/home-entropy-check.mjs | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/scripts/home-entropy-check.mjs b/scripts/home-entropy-check.mjs index b972d6acc..cfbeeb67a 100755 --- a/scripts/home-entropy-check.mjs +++ b/scripts/home-entropy-check.mjs @@ -1868,7 +1868,11 @@ assert( includesNormalized(agentsContract, "Before deleting a duplicate ref, prove exact commit identity") && includesNormalized(agentsContract, "Before deleting a worktree, verify its status, untracked files, open files/processes, and protecting ref") && agentsContract.includes("VERDICT: PASS") && - agentsContract.includes("different model") && + includesNormalized(agentsContract, "Each task change needs one independent development review marked PASS") && + includesNormalized(agentsContract, "from a different model family than its author") && + includesNormalized(agentsContract, "verify that the posted verdict covers the current candidate") && + includesNormalized(agentsContract, "Weekly release PRs still need his approval before merge and tag; when he is the author, Anders reviews") && + includesNormalized(agentsContract, "`irzhywau` for security follow-up: he reviews merged security task PRs") && agentsContract.includes("elastos-pr-review "), "Root AGENTS.md must preserve standing branch roles, fetched-base selection, target proof, public-live approval and Browser claim discipline", ); From c173cf5b248040e44b468085feb447c03fe8735b Mon Sep 17 00:00:00 2001 From: Anders Alm Date: Fri, 2 Oct 2026 15:53:24 -0500 Subject: [PATCH 5/5] docs: assign authored security follow-up to Anders --- AGENTS.md | 1 + scripts/home-entropy-check.mjs | 1 + 2 files changed, 2 insertions(+) diff --git a/AGENTS.md b/AGENTS.md index 60e8db116..2dc84b115 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -267,6 +267,7 @@ capsules, provider config, and `components.json`. Keep explicit human acceptance gates recorded in the owning issue. Request `irzhywau` for security follow-up: he reviews merged security task PRs, and a finding goes into an existing issue or a revert when it reopens a hole. + When he authors a security task PR, Anders conducts the follow-up review. Weekly release PRs still need his approval before merge and tag; when he is the author, Anders reviews. Also request the feature owner when required. - Use one development review round per coherent change. Resolve findings in diff --git a/scripts/home-entropy-check.mjs b/scripts/home-entropy-check.mjs index cfbeeb67a..5011f047e 100755 --- a/scripts/home-entropy-check.mjs +++ b/scripts/home-entropy-check.mjs @@ -1873,6 +1873,7 @@ assert( includesNormalized(agentsContract, "verify that the posted verdict covers the current candidate") && includesNormalized(agentsContract, "Weekly release PRs still need his approval before merge and tag; when he is the author, Anders reviews") && includesNormalized(agentsContract, "`irzhywau` for security follow-up: he reviews merged security task PRs") && + includesNormalized(agentsContract, "When he authors a security task PR, Anders conducts the follow-up review") && agentsContract.includes("elastos-pr-review "), "Root AGENTS.md must preserve standing branch roles, fetched-base selection, target proof, public-live approval and Browser claim discipline", );