|
| 1 | +# Change Management Rule (ISO 27001) |
| 2 | + |
| 3 | +All code and content changes must follow a traceable workflow that an auditor |
| 4 | +can verify: **issue → branch → PR → merge → verify**. |
| 5 | + |
| 6 | +## Standard Workflow |
| 7 | + |
| 8 | +Every change that modifies behavior, configuration, content, or dependencies: |
| 9 | + |
| 10 | +1. **Issue first.** Create a GitHub issue describing the change before starting |
| 11 | + work. If an issue already exists, reference it. |
| 12 | +2. **Branch.** Create a feature branch from `main` named |
| 13 | + `{type}/{short-description}` (e.g., `feat/engagement-model`, |
| 14 | + `fix/css-banner-edge-case`). |
| 15 | +3. **Work.** Make changes on the branch. Run preflight checks before committing. |
| 16 | +4. **PR.** Create a pull request linking to the issue with `Closes #N` or |
| 17 | + `Fixes #N` in the body. PR body must include a Summary and Test Plan. |
| 18 | +5. **Merge.** Merge with `gh pr merge --admin --merge --delete-branch` (org |
| 19 | + policy blocks auto-merge; admin override is authorized for the repo owner). |
| 20 | +6. **Post-merge verification.** After every merge to main: |
| 21 | + - Check GitHub CI: `gh run list --limit 3` |
| 22 | + - Check Cloudflare build logs (docs site deploys to CF Workers): verify the |
| 23 | + build succeeds |
| 24 | + - Check Dependabot: |
| 25 | + `gh api repos/RickCogley/hibana/dependabot/alerts --jq '[.[] | select(.state=="open")] | length'` |
| 26 | + — address any new alerts |
| 27 | +7. **Release.** Releases are created periodically via |
| 28 | + `gh release create v<x.y.z>` with hand-written notes. **deno.land/x** |
| 29 | + auto-publishes from the tag via webhook (no GitHub Action involvement). JSR |
| 30 | + is intentionally not used — Lume's dev resists JSR because JSR doesn't |
| 31 | + support http imports, and hibana follows Lume's hosting choice so it can be |
| 32 | + pulled into Lume cleanly. |
| 33 | + |
| 34 | +## Branching correctly |
| 35 | + |
| 36 | +Use `git switch -c <branch>` from main, NOT |
| 37 | +`git checkout origin/main -b <branch>` (the latter sets the upstream to |
| 38 | +`origin/main`, which can cause `git push -u origin <branch>` to push directly to |
| 39 | +main and bypass review). |
| 40 | + |
| 41 | +```bash |
| 42 | +git switch main && git pull --ff-only |
| 43 | +git switch -c feat/whatever |
| 44 | +# ...work... |
| 45 | +git push -u origin HEAD |
| 46 | +``` |
| 47 | + |
| 48 | +Pre-push sanity check on a new branch: |
| 49 | + |
| 50 | +```bash |
| 51 | +git branch -vv |
| 52 | +# Current branch should NOT show [origin/main] or any [origin/something-else] |
| 53 | +# upstream. An unset upstream (no brackets) is what you want. |
| 54 | +``` |
| 55 | + |
| 56 | +## Writing PR and issue bodies |
| 57 | + |
| 58 | +Always pass multi-line or markdown-rich bodies **by file**, never inline via a |
| 59 | +heredoc: |
| 60 | + |
| 61 | +```bash |
| 62 | +gh pr create --body-file <path> |
| 63 | +gh pr edit N --body-file <path> |
| 64 | +gh issue create --body-file <path> |
| 65 | +git commit -F <path> |
| 66 | +``` |
| 67 | + |
| 68 | +Heredocs cause backslash artifacts in rendered markdown. |
| 69 | + |
| 70 | +## Conventional Commits |
| 71 | + |
| 72 | +``` |
| 73 | +type(scope): description |
| 74 | +
|
| 75 | +Body explaining the change (if needed). |
| 76 | +
|
| 77 | +InfoSec: [security/quality/privacy consideration] |
| 78 | +``` |
| 79 | + |
| 80 | +**Types:** `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore` |
| 81 | + |
| 82 | +**InfoSec line** — required for all changes. Examples: |
| 83 | + |
| 84 | +- `InfoSec: input validation added for user-supplied query parameters` |
| 85 | +- `InfoSec: no security impact — content-only change` |
| 86 | +- `InfoSec: dependency update addresses CVE-2026-XXXX` |
| 87 | + |
| 88 | +If a change has no security implications, state that explicitly. |
| 89 | + |
| 90 | +## Rationale |
| 91 | + |
| 92 | +This workflow produces the evidence chain that ISO 27001 (A.8.9, A.8.25, A.8.32) |
| 93 | +requires: |
| 94 | + |
| 95 | +- **Change request** → GitHub issue |
| 96 | +- **Authorization** → PR review and merge approval |
| 97 | +- **Testing** → CI checks |
| 98 | +- **Implementation** → Commits on feature branch |
| 99 | +- **Verification** → Post-merge CI confirmation |
| 100 | + |
| 101 | +An auditor can trace any production change from PR → issue → commits → CI |
| 102 | +results. |
| 103 | + |
| 104 | +--- |
| 105 | + |
| 106 | +_Originally synced from |
| 107 | +[eSolia/devkit](https://github.com/eSolia/devkit)/.claude/shared-rules/change-management.md. |
| 108 | +This repo is not a devkit sync consumer — edit locally as needed._ |
0 commit comments