jb/harness-tools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Make development workflow risk-based and verification proportionate

Browse Source
This commit is contained in:
jb
2026-10-07 17:43:19 -04:00
parent 284fdd638d
commit 0cc0e82bbc
13 changed files with 265 additions and 173 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/develop/develop-workflow/references/git-and-integration.md
+13 -24
View File
@@ -2,39 +2,28 @@
## Isolation
Record the source branch and exact base before creating `./.worktrees/<feature>` on `feature/<feature>`. Prove every shell location with explicit `cd` or `git -C`; verify `git rev-parse --show-toplevel` before mutation. Block on collisions, unmerged paths, unexpected ownership, or an unignored worktree root. Never rename, reset, clean, stash, copy source changes, or remove an orphan silently.
Record the source branch and exact base before creating `./.worktrees/<feature>` on `feature/<feature>`. Prove shell locations with explicit `cd` or `git -C`; verify `git rev-parse --show-toplevel` before mutation. Block on collisions, unmerged paths, unexpected ownership, or an unignored worktree root. Never rename, reset, clean, stash, copy source changes, or remove an orphan silently.
A dirty source checkout requires bounded status/path evidence and explicit approval because its changes are omitted. Preserve that evidence in the record.
A dirty source checkout requires bounded status/path evidence and explicit approval because its changes are omitted. Preserve that evidence in the record. Do not disturb another workflow's worktree or changes.
## Synchronize and pin review
After focused commits and verification:
Fetch the latest source branch when a remote exists and rebase onto the intended latest source commit before final verification where practical. Inspect any resulting delta and apply [verification invalidation](verification.md#reuse-and-invalidation); rerun affected checks rather than restarting all phases automatically. Ask before resolving conflicts that change agreed behavior, rewriting shared history, force operations, or non-fast-forward integration.
1. Fetch the latest source branch when a remote exists.
2. Rebase the feature branch onto the latest source commit.
3. Rerun affected checks and full required verification whenever rebase changes the effective tree or resolves conflicts.
4. Record the review base, product HEAD, clean status, tree hash, and commit list.
5. Generate exact review bytes:
Create focused commits after their applicable checks pass. Pin the review base, product HEAD, clean status, tree hash, commit list, exact binary diff command, and digest using [review policy](review-and-remediation.md). Keep product approval attached to immutable evidence, including targeted follow-up on subsequent fixes.
```bash
git diff --binary --full-index --find-renames <base>...<product-head> --
```
6. Hash those bytes with SHA-256 and record the command and digest. Regenerate from the durable commits rather than committing a duplicate patch.
Ask before conflict resolution changes approved behavior, history rewrite of shared work, force operations, or non-fast-forward integration.
Update the record at meaningful boundaries and batch it with related commits. Neither an initial record-only commit nor a commit per decision is mandatory. A saved, uncommitted record is recovery evidence, but verify it against Git rather than assuming it was previously committed.
## Fast-forward integration
After both review axes approve the exact fingerprint:
After independent review and final required verification:
1. Confirm the source branch still equals the final rebase base. Return to synchronize, verify, and review if it advanced.
1. Confirm the source branch still equals the integration base. If it advanced, inspect the delta, synchronize, invalidate affected checks, and refresh review coverage for changed interactions. Reuse unaffected evidence only with justification.
2. Confirm the source checkout exists, is clean, and is safe to update. Stop when dirty or missing.
3. Fast-forward the source branch to the reviewed feature branch; create no merge commit.
4. In the source checkout, update only the workflow record with bound review and integration evidence.
5. Prove the closure diff touches only that record, run applicable documentation checks, and create one metadata-only closure commit.
6. Run a cheap final sanity check.
7. Prove the product and closure commits reachable from the source branch.
8. Remove the completed worktree, then delete its feature branch.
3. Confirm the final product changes are covered by review and verification. Evidence-only updates to the workflow record may follow review only after proving they change results/status, not scope, acceptance, policy, or executable instructions. Review other changes normally.
4. Fast-forward the source branch to the feature branch; create no merge commit.
5. Save integration evidence in the record. Batch it with a pending evidence update or use an optional record-only commit when needed to retain final results. Prove any post-review evidence commit touches only the record and run its applicable checks; there is no mandatory separate closure-commit gate.
6. Run a cheap sanity check, prove all product and retained evidence commits reachable from the source branch, and verify clean source/worktree state.
7. Remove only the workflow-owned worktree, then delete its feature branch.
Treat cleanup in step 8 as pre-authorized only after every preceding clean-state and reachability proof. Ask before any other destructive cleanup. Pushing, publishing, deployment, and production access remain separate user actions.
Cleanup in step 7 is pre-authorized only after the ownership, reachability, and clean-state proofs. Ask before other destructive cleanup. Push, publish, deployment, and production access remain separate scoped actions.