zernie
a0e8cf26ce
The self-audit was C (70) with Safety at 70: all four model-invocable skills declared no allowed-tools, so each inherited every tool and tripped the repo's own lethal-trifecta check. vigiles shipping a harness its own Safety ring marks down is the exact false confidence this project exists to catch. The contracts are the real ones, not the minimum that silences the check. None of the four needs web access — verified, not assumed: debug-my-harness only reads the local flight-recorder ledger, so it is read-only (Read, Glob, Grep); edit-spec, strengthen, and test-harness edit local files and shell out to npm/npx, so they take Bash but no web tool. Without a leg-B tool they hold at most two trifecta legs, which is the Rule of Two the detector encodes, so the finding clears because the capability really is narrower. adopt-spec and linter-docs are untouched — they carry disable-model-invocation and are out of scope for the check. Self-audit is now A (100), Safety 100. Tested stays 67 and advisory. Also gives the code of conduct a reporting path that resolves when the maintainer's profile carries no public contact, or when the concern is about the maintainer.
2.1 KiB
Code of Conduct
Our pledge
We want vigiles to be a project where people can report a bug, disagree with a design decision, or show up knowing nothing, without it costing them anything. Everyone participating — issues, pull requests, discussions, reviews — is expected to help keep it that way.
Expected behaviour
- Assume the other person is acting in good faith, especially when reading a terse message.
- Critique the code, the config, or the claim — not the person who wrote it.
- Accept that maintainer time is finite. An unanswered issue is usually a queue, not a snub.
- When you disagree, say what you'd do instead.
Unacceptable behaviour
- Harassment, personal attacks, or demeaning comments — including about someone's experience level.
- Sexualised language or imagery, or unwelcome attention of any kind.
- Publishing someone's private information without their explicit permission.
- Sustained disruption of discussions, or deliberately derailing threads.
Scope
This applies in all project spaces — the repository, its issues and pull requests, and its discussions — and when someone is representing the project in public.
Reporting
Report a concern privately to the maintainer — the contact on their GitHub profile, or a DM on any platform linked there. If you'd rather not contact the maintainer directly, or the concern is about them, use GitHub's own report abuse flow, which goes to GitHub staff instead.
Reports are handled confidentially, and the person reporting will not be named without their agreement.
Reports about a security vulnerability go somewhere else — see SECURITY.md.
Enforcement
vigiles is maintained by one person, so this is a statement of intent, not a committee process. Depending on severity, a response may be a private word, an edited or removed comment, or a block from the repository. Maintainers who don't follow this themselves should be called on it.
Attribution
Adapted from the Contributor Covenant, version 2.1.