Charter v69: a Ctrl-C stops the checks one after another, and a check that uses the terminal fails

• A Ctrl-C stops the checks run one after another (#494, found by DEV on PR #493). With the
  checks one after another, the default, a SIGINT did not stop the pre-push checks when the check
  running ended normally on it, as a check that handles SIGINT and exits does: the run went on to
  the next check, and to every one after it. A SIGINT now ends the run with exit 130, a SIGHUP with
  129 and a SIGTERM with 143, in both modes, and the run stops each check with what it started.
• A check that uses the terminal fails, saying so, instead of holding the push (#494, found by
  QA in its review of PR #497). Each check now runs apart from the terminal, one after another too,
  as side by side since v67. A check that reads the terminal, or writes to it once stty tostop is
  set, as git's pager can, is stopped by it: the run now fails that check within about a second,
  saying stopped: it read the terminal, and goes on. Side by side, such a check held the run for
  good. The README's FAQ states the rule for both modes.
• This repository's own tests hold on a loaded machine (#485, #487, #490, #491, #498). Several
  failed pushes here when the Mac was loaded, or could hold the checks for good; each time limit in
  them now only guards against a hang. They do not ship, so nothing changes for a project.
• Upgrading from v68: nothing to do by hand, unless one of the project's checks uses the
  terminal, which now fails it. No session needs a restart: no rule of the charter changes.

Charter v68: a release branch can be cut from a tag without an exception

• A release branch can be cut from a tag without an exception (#482, reported by
  trivial-tape's CTO). Since v66 the pre-push gate refused every push to a declared release branch,
  even one that only created it at a released commit, so each patch release needed an exception
  from the CEO. §2.3: a push that creates a release branch at a commit that the remote's default
  branch, one of its release branches or one of its tags already holds now goes through with no
  exception and runs no check, which covers a tag whose release branch was merged and deleted. One
  that moves a release branch, or creates it at a commit that only a feature branch holds, is
  refused as before (found by QA in its review of PR #484). The README says how to cut one from
  its tag.
• A push of a commit that a remote tag holds runs no check (#482). The gate now lists the
  remote's tags as well as its branches, and asks git once whether any of them holds the pushed
  commit, so the tags add no measurable time (QA's finding in its review of PR #484).
• Upgrading from v67: nothing to do by hand. Restart the three sessions, since §2.3 changes.

Charter v67: the pre-push keeps the Mac awake and can run its checks side by side, and a version PR checks itself

• The pre-push checks can run side by side (#459). A project opts in with the line
  # squad-checks: side by side in .agent-squad-checks, and its checks then all start at once.
  Each keeps its status line, the output of one that fails is shown, and the push is refused when
  any fails. Interrupted, the run stops every check and what each started. Without the line,
  nothing changes. The README says when two checks could clash, as over a port or a database.
  This repository opts in: its checks take 94 to 108 s instead of 261 to 273 s.
• The pre-push checks keep the Mac awake while they run (#458). On 2026-10-18 a push failed
  because the Mac idle-slept during its checks: Claude Code keeps the machine awake only five
  minutes at a time, which seems not to be renewed during one long command. squad-checks.sh now
  holds caffeinate -i for as long as it runs, and lets go once it ends, however it ends. Off
  macOS, the checks run as before.
• A reference to a third-party issue or PR counts as posting there (#463). §6: GitHub copies a
  reference written as owner/repo#N, or as its link, to the other repository's page, where
  neither an edit nor a deletion removes it. So it needs the CEO's authorisation, as any post
  outside does.
• A version PR that GitHub links to an issue is pointed out (#461). On v65, "are all closed:
  #428" in a version PR's evidence made GitHub link it to #428, and the plan's Version PR row
  dropped it without a word. The row now shows such a PR and names each stray link, and the merge
  gate stops a PR that names a plan issue and has one. Both say to write Closes #N for an issue
  the PR means to close, and to reword the rest (#475, found by QA in its review of PR #474).
• The plan's table shows an install by a later release, and a delegated README read (#462).
  A release that a later one brought in shows its install as done, naming that release. §3: a
  line of the plan issue's description that starts with README read by:, and names the role and
  the reason, puts the read on that role's row.
• The squad board names the release /squad-update reported (#477, found by the CEO). The
  command read the latest release from GitHub, but left the board's notice offering an older one
  until the next daily check. /squad-update and /squad-upgrade now refresh it.
• A dry run of the uninstaller copies nothing (#473). The uninstaller runs from a temporary
  copy of itself, and it made that copy even for a dry run, a refusal or bad usage. It now makes
  it only when it removes something. With CI's kcov now writing its reports at the end, that ends
  a race that left the coverage report short.
• The README shows the plan as GitHub renders it (#466, the CEO's idea). The features list
  names the squad's work on GitHub, and a screenshot of a plan issue follows it.
• Upgrading from v66: nothing to do by hand. A project that wants its checks side by side adds
  the line to .agent-squad-checks once it knows they do not clash. Restart the three sessions,
  since §3 and §6 change.

Charter v66: release branches are held as main is, and a push outlasts long checks over ssh

• A release branch is held as main is (#441, reported by trivial-tape's CTO from its QA's
  finding; #446; and #450, found by QA in its review of PR #449). trivial-tape ships 0.15.2 from
  release/0.15 while main carries 0.16, and the pre-push gate let a direct push to that branch
  through, since it held the default branch alone. §2.3: a project lists the patterns of its
  release branches in .agent-squad-release-branches, at its root, in the form of
  .agent-squad-checks. Only a PR reviewed by QA changes a branch that matches, with the same
  exception as main. The pre-push gate refuses a direct push to one, and reads the declaration
  from the default branch's tip, so that a push cannot lift it with its own commit. A push by URL
  is held as one by the name of the remote whose URL or push URL it is, for the default branch as
  for a release branch. A fix goes to main first, and a backport, a PR that names the PR it
  carries (Backport of #M), takes it to the release branch: §2.4, §3, §4.1, §4.2, §5 and §6 say
  so. BOOTSTRAP's row 6 protects the release branches on GitHub, and templates/AGENTS.md
  records them.
• A push whose checks take minutes reaches the remote over ssh (#438, found by DEV on PR
  #436). git push opens its ssh connection before the pre-push checks run. On 2026-10-18 the
  connection was closed while it sat idle through 7 minutes of checks, so the push died of a
  broken pipe once they had passed. The installer now sets core.sshCommand to
  ssh -o ServerAliveInterval=30 in the project's own .git/config. It leaves alone a
  core.sshCommand that the project or the machine has set already, and a GIT_SSH, which it
  would override. --check has an item for it, and the uninstaller removes it. After checks that
  ran longer than SQUAD_LONG_CHECKS seconds, 120 by default, the gate's last line says that a
  broken pipe from git then means the connection closed while they ran, and that the push should
  be made again. With the keepalive, a push came through an 8-minute hook; without it, it died at
  482 s.
• Upgrading from v65: the installer sets the keepalive itself, and says so. A project with
  release branches lists them in .agent-squad-release-branches and commits the file to main
  through a PR. It also protects them on GitHub as it protects main (BOOTSTRAP.md, row 6), and
  records them in AGENTS.md. A project without release branches has nothing to do by hand. Then
  restart the three sessions, since §1, §2.3, §2.4, §3, §4, §5 and §6 change.

Charter v65: GitHub calls are bounded, a downgrade names the sessions to restart, and the plan knows a release without a read

• A GitHub call that never answers ends, and the stall watch goes on (#430, #437, and #439,
  found by QA in its review of PR #436). On 2026-10-18 a /squad-watch pass hung for 2 h 21 min
  on a gh call whose connection died while the Mac slept, and the passes after it queued up
  behind it. The new scripts/squad-timeout.sh bounds a command by wall-clock time, which moves on
  while the machine sleeps, unlike sleep, alarm or GNU timeout. Past the bound, it stops the
  command and every process the command started, such as a git call's ssh. A command that ends
  in time returns as soon as it ends. squad-stalls.sh, squad-outside.sh and squad-plan.sh run each GitHub call
  through it, 120 s by default (SQUAD_GH_TIMEOUT), and exit 1 with a message that says so when a
  call does not answer. squad-latest.sh keeps its exit 0, and its line says when GitHub did not
  answer within its 10 s.
• Every other call to GitHub or to the remote ends too (#435). The session hooks' snapshot,
  the merge gate, squad-set-status.sh, squad-setup-labels.sh, the installer and the pre-push
  gate run each such call through squad-timeout.sh. The bound is 120 s, or 10 s in the session
  hooks. A call that never answers fails, and the script says so. The snapshot reads
  (GitHub did not answer within 10 s). A pre-push gate whose remote did not list its branches
  counts every ref pushed as new code.
• Going back to an older release names the sessions to restart (#428, found by QA in its
  review of PR #427). After a downgrade, squad-sessions.sh said that every session ran the
  installed release, though each still ran the newer squad board until it restarted. It now names
  a session on a newer release than the installed one to restart, as it names one on an older
  release, and the band marks it the same way. /squad-upgrade, /squad-resume and the README
  say so.
• The plan's table knows a release that takes no README read (#429). §3: the CTO's note that a
  release which only fixes things takes no read is a line of the plan issue's description, outside
  its markers, that starts with No README read: and gives the reason. The table's README row
  then shows the read as not taken, with that reason, before and after the tag, and the stall
  watch asks for no read. Until now the row asked for a read, and showed one as done once tagged.
• Outside the release, already live: install.sh runs from main, and it now bounds its own
  calls to GitHub the same way. When one never answers, it exits 2 with nothing installed (#435).
• Upgrading from v64: nothing to do by hand. Re-read §3's paragraph on plan issues, and
  restart the three sessions to load the new squad board.

Charter v64: going back to an older release names the rules it takes back

• Going back to an older release names the rules it takes back (#425, found by QA in its
  review of PR #424). /squad-upgrade vN to a release older than the one the project runs read
  that release's CHANGELOG.md, which has no entry above the running version, and so told DEV, QA
  and the CEO that no rule changed. It now reads the installed playbook's CHANGELOG.md before the
  install replaces it, names the rules that revert, with their § numbers, to DEV and QA and in its
  report, and ends with the headlines of the releases it takes back.
• Upgrading from v63: nothing to do. No rule changes, and the command takes effect at once. A
  restart only brings the squad board's version up to date.

Charter v63: /squad-update tells what a newer release changes, and /squad-upgrade installs it in one step

• /squad-update tells, /squad-upgrade installs (#422, the CEO's decision). /squad-update
  tells what a newer release changes, as /squad-upgrade did, and installs nothing.
  /squad-upgrade installs the latest release, and /squad-upgrade vN a given one, with no
  question, since typing it is the CEO's yes; it need not follow /squad-update. It still brings
  the agents to a safe point first, stops and tells the CEO when a step is left undone or the check
  fails, and asks for the restart and /squad-resume. It ends with the version installed and its
  release's headlines. The squad board's notice of a newer release names /squad-update. §7 says
  so.
• Upgrading from v62: nothing to do by hand. Restart the three sessions, so that each loads the
  new §7 and the board's new notice. This upgrade still runs v62's /squad-upgrade, which asks
  first; from v63 on, it installs without asking.

Charter v62: one copy of the instructions in a worktree, and a shorter charter

• A session in its worktree loads the project's instructions once (#416, reported by
  rogue-trader's squad). Until now, the first Read, Edit or Write in a worktree also loaded that
  worktree's copy of CLAUDE.md, beside the main checkout's: about 48k tokens more per session in
  rogue-trader, and again after each compaction. The installer now writes Claude Code's
  claudeMdExcludes into .claude/settings.local.json for each worktree's CLAUDE.md,
  .claude/CLAUDE.md and .claude/rules/, and keeps the project's own entries; a CLAUDE.md in
  a worktree's subdirectory still loads. --check verifies the entries, and the uninstaller
  removes them.
• The charter's italic notes give a rule's reason, not the story of its incident (#417, the
  CEO's decision). The 13 notes that only told an incident go, and 20 others keep only their
  reason, in a sentence. No rule changes. The charter is about 700 words shorter, and the README
  says that each rule comes with its reason.
• Upgrading from v61: nothing to do by hand, since the installer writes the setting. Restart
  the three sessions, so that each loads the shorter charter and starts with the setting.

Charter v61: /squad-upgrade's pause relay gives the time it was sent

• /squad-upgrade's pause relay gives the time it was sent (#413, noticed by DEV and QA at the
  v58 and v60 upgrades). Its step 4 ends the message with the same "Sent at" line as
  /squad-pause, as §6 asks of every relayed step-away message, and a check of this repository
  fails when a command that relays one leaves the line out.
• Upgrading from v60: nothing to do. No rule changes, and the command takes effect at once. A
  restart only brings the squad board's version up to date.

Charter v60: a release that only fixes things takes no README read

• A release that only fixes things takes no README read (#410, the CEO's decision). §3: when
  the README is unchanged since the last tag, and the CHANGELOG entry adds no rule and nothing a
  user notices, the CTO says so on the plan issue in one line and tags the release. The install
  still waits for the CEO's yes.
• Upgrading from v59: restart the three sessions, as /squad-upgrade asks, since §3 changes.
  Nothing else.