Dual-VCS commit cadence: agents commit each change-set to both git and fossil by default
Root AGENTS.md User Preferences gains the cadence rule (user, 2026-07-29):
in this dual-VCS tree a request to commit means BOTH git and fossil in the
same work unit - only an explicit single-VCS instruction narrows it. The
fossil checkin mirrors the git commit (same message body; adds/renames via
explicit fossil add / fossil mv). Before each fossil checkin, `fossil
changes` is checked for pending material beyond the current change-set:
the developer may commit to git and let fossil lag, so secondary catch-up
checkins remain a normal event - land one first, or fold the lag in with a
message naming the covered git commits.
This retires the catch-up-only working practice (fossil deferred until a
requested catch-up), which was never recorded in AGENTS.md and created
more work per catch-up than as-we-go mirroring.
.fossil-settings/AGENTS.md Work Guidance gains a pointer to the rule
(coexistence-contract readers find the cadence from there); CLAUDE.md
Commit Conventions gains the one-line dual-VCS reminder for Claude
harnesses.
Doc-only; no version bump.
Assisted-by: harness=claude; primary-model=claude-fable-5; api-location=anthropic.com
@ -43,6 +43,8 @@ Ignore-rule changes never land one-sided: any agent edit to `.gitignore` include
## Work Guidance
- Commit cadence for this dual-VCS tree (agents commit each change-set to both git and fossil in the same work unit; catch-up checkins when fossil has lagged behind developer git commits) is governed by root `AGENTS.md` User Preferences.
@ -99,6 +99,7 @@ When the user requests a durable behavior change, record it here or in the relev
- Tcl has no `-e`/`-c` one-liner flag (a reflex agents carry over from perl/python/node). Stock `tclsh`/`tclsh86`/`tclsh90` recognise only `-encoding name` as a leading option; any other argument starting with `-` is NOT treated as a script file - all arguments land in `$argv` and tclsh reads commands from stdin. On a console that hangs forever at an interactive prompt; with piped/redirected stdin it exits 0 having silently ignored the supposed one-liner and executed stdin instead. (The punk kits differ: they treat `-e` as a script filename and error out immediately - no hang, but still no one-liner.) To run ad-hoc Tcl: write a temp `.tcl` file and run `tclsh path/to/file.tcl`, or pipe the script to stdin (`echo 'puts hi' | tclsh`, or a bash heredoc). Defensive habit regardless: when exec'ing tclsh non-interactively, redirect stdin (`</dev/null`, `< NUL`) so a mis-invocation exits at EOF instead of hanging.
- For ad-hoc punkshell scripts that need working-tree modules, use `bin/punk91 src script` for stdin scripts or `bin/punk91 src script path/to/file.tcl` for script files. Do not use `bin/punk91 src` for piped/redirected snippets: `src` alone starts the live shell on the repo source tree and may execute stdin input but then remain in shell/eof handling instead of exiting cleanly. Keep `src` before `script` so the working-tree modules are loaded.
- VCS ignore rules are dual-tracked (git + fossil). An agent that changes ignore rules in one VCS must make the equivalent change in the other in the same work unit: `.gitignore` is the canonical statement of intent and `.fossil-settings/ignore-glob` is hand-derived from it, never the reverse - so a `.gitignore` edit includes deriving the ignore-glob translation, and an ignore-glob-only edit is wrong unless it is purely catching up to `.gitignore`. Fossil globs differ semantically (no negation - tracked exceptions need explicit `fossil add`; case-sensitive; `*` crosses `/`): translate per the derivation rules in `.fossil-settings/AGENTS.md` and run its verification checks before committing.
- Dual-VCS commit cadence (user, 2026-07-29): in a tree tracked by both git and fossil (this repo; git is primary), agents commit each change-set to BOTH VCS in the same work unit by default - a request to commit means both, and only an explicit single-VCS instruction narrows it. The fossil checkin mirrors the git commit (same message body; new/renamed files need explicit `fossil add` / `fossil mv`). Before the fossil checkin, run `fossil changes` and look for pending material beyond the current change-set: the developer may commit to git manually and let fossil lag, and a plain `fossil commit` sweeps everything pending - when lag is present, either land a separate catch-up checkin first, or fold the lag in with a message naming the covered git commits (per-change rationale stays in git history; the catch-up message summarizes). Coexistence mechanics (ignore sync, CRLF prompt avoidance, tracked-set verification) are in `.fossil-settings/AGENTS.md`.
- Throwaway fossil repositories (test/experiment repos an agent creates, e.g. in a session scratchpad) must not register in the user's real global fossil config-db: `fossil init`/`fossil open` write persistent `repo:`/`ckout:` rows into `%LOCALAPPDATA%\_fossil`, which is the enumeration source for `dev projects.work` project discovery (G-016/G-017). Set `FOSSIL_HOME` to a disposable scratch directory for the duration of such fossil commands (both fossil and `punk::repo::fossil_get_configdb` honour it first). If pollution has already occurred: `fossil all ignore <repo-path>`, delete the directory, then any `fossil all` command prunes the orphaned `ckout:` row.
- Fossil checkout branch discipline: in fossil, `tip` means the newest check-in on ANY branch - not the trunk tip. A `fossil open ... tip` or `fossil update tip` run shortly after an upstream feature-branch commit silently parks the checkout on that branch, and every later plain `fossil update` keeps following it. When opening or refreshing any fossil checkout (including reference checkouts such as `TEMP_REFERENCE/tcl9`), name the branch explicitly (`fossil update trunk`), never `tip`, and confirm the `tags:` line of `fossil status` shows the intended branch afterwards.
- Do not commit new executable binaries (shared libs, .exe, native .so/.dll/.dylib, bare ELF/Mach-O, or zip-based .tm modules embedding executables) to the repository. Existing binaries in `bin/`, `src/vfs/`, `src/vendorlib/`, `src/vendormodules/`, and `src/bootsupport/` are there intentionally pending the build/retrieval infrastructure tracked by goals G-004/G-005/G-006; do not flag, "fix", or hassle the developer about these — they are known and will be removed once G-005 (zig build) or G-006 (pre-built download) provides an alternative. This rule stops agents from adding new binaries; it does not block the developer's interim commits of existing vendor/vfs binaries. It is workflow policy only - deliberately NOT enforced at the local VCS layer: fossil `binary-glob` is `*` (versioned in `.fossil-settings/`) so binary checkins proceed without warnings/prompts, here and in sub-projects like tomlish.
@ -11,3 +11,4 @@ If this file conflicts with `AGENTS.md`, `AGENTS.md` wins.
- Never add "Co-Authored-By" lines or any AI-attribution footers to commit messages - git commits and fossil checkins alike.
- When an agent constructs and executes the commit command itself (`git commit`, `fossil commit` - staging, composing the message, and committing), it must append one `Assisted-by` trailer as the last line of the commit message. If the user commits manually, no trailer is required.
- Trailer format and field derivation rules live in the root `AGENTS.md` "Commit Conventions (any VCS)" section. `AGENTS.md` is the source of truth; this section is a reminder that the policy applies to Claude harnesses too.
- This tree is dual-VCS (git + fossil): an agent-executed commit lands in BOTH VCS in the same work unit by default. Cadence and catch-up rules live in root `AGENTS.md` User Preferences.
