mchus/bible
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Compress always-on contracts and restore pagination fields

Browse Source 
The always-on set is paid by every session, so it gets the tightest
form: git-sync-check shrinks to its procedural core, testing-policy
moves the table-test example to README.md and folds the agent
instructions into the rules, go-code-style inlines the error-wrapping
example. Per-session read cost drops from 403 to 336 lines.

Also restore the pagination response fields in table-management: the
previous dedup replaced them with a reference to go-api, which the
table router line does not load.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Michael Chus
2026-06-12 10:05:00 +03:00
parent a44133aff2
commit 0005f3e41a
5 changed files with 53 additions and 93 deletions
Download Patch File Download Diff File Expand all files Collapse all files

47
rules/patterns/git-sync-check/contract.md
View File

@@ -2,40 +2,21 @@
## Rule
Before starting any work on a task, check whether the remote repository has commits that are not yet present locally.
This rule assumes the repository is hosted in Gitea.
Use neutral `git` commands for sync checks and branch management, and use Gitea terminology for server-side review flow (`pull request`, not `merge request`).
Before starting any work on a task (repositories are hosted in Gitea):
## Required Steps
1. `git fetch origin`
2. `git log HEAD..@{u} --oneline`
3. Non-empty output: **stop immediately, make no changes**, tell the user the remote has
new commits and ask how to proceed (pull, rebase, ignore).
4. Empty output: proceed normally.
1. Run `git fetch origin` to update remote-tracking refs from the Gitea remote without merging.
2. Check for upstream commits: `git log HEAD..@{u} --oneline`.
3. If the output is non-empty (there are new remote commits):
- **Stop immediately. Do not make any changes.**
- Inform the user that the remote has new commits and ask how to proceed (e.g., pull, rebase, or ignore).
4. If the output is empty, proceed with the task normally.
If offline and fetch is impossible: notify the user before proceeding.
Web UI inspection does not replace the local check.
## Gitea Workflow Notes
## Gitea Workflow
- Verify the remote when needed: `git remote -v`
- Create a task branch before changes: `git checkout -b <task-branch>`
- Push the branch to Gitea and set upstream: `git push -u origin <task-branch>`
- Open the review in Gitea as a pull request against the target branch.
- If the `tea` CLI is configured for the environment, it may be used for Gitea pull request actions such as:
- `tea pr list`
- `tea pr create`
- `tea pr checkout <number>`
## Forbidden Assumptions
- Do not assume GitHub-specific tooling such as `gh`.
- Do not use GitLab terminology such as `merge request` unless a project explicitly defines that workflow separately.
- Do not replace the required sync check with web UI inspection in Gitea; the local `git fetch origin` and `git log HEAD..@{u} --oneline` check remains mandatory.
## Rationale
Working on an outdated local state risks merge conflicts, duplicate work, and overwriting changes made by other contributors. Checking remote state first keeps the working tree aligned and prevents avoidable conflicts. Using Gitea-specific review terminology and examples also avoids workflow confusion in repositories that are not hosted on GitHub or GitLab.
## Exceptions
- Offline environments where `git fetch origin` is not possible: notify the user that the check could not be performed before proceeding.
- Create a task branch before changes (`git checkout -b <branch>`), push with
`git push -u origin <branch>`, review via a Gitea **pull request** (the `tea` CLI may be
used if configured).
- Do not assume GitHub tooling such as `gh`; do not use GitLab terminology such as
`merge request`.