Summary
Description, HTTP status, and typical remediation.
Background
We rely on this information internally but it is currently tribal knowledge. Writing it down lets reviewers verify behaviour against the documented intent, lets new contributors get productive without reading every commit, and lets the support team answer common questions without paging an engineer.
Acceptance criteria
Implementation hints
- Audience: pick one (contributor / operator / downstream integrator) and write for them; do not try to address all three in the same doc.
- Prefer concrete examples over abstract definitions. Show a real entrypoint, request, or output rather than
foo() placeholders.
- Cross-link from the README and from any related doc; orphaned docs rot fastest.
- Where the project ships generated docs (rustdoc, JSDoc, OpenAPI), keep this new content discoverable from the same starting point.
Repo-specific notes
- Run
npx tsc --noEmit, npm test, and the security:scan / sbom:check scripts locally before pushing.
- Any new request or response shape must have a matching Zod schema and a regenerated OpenAPI entry.
- New env vars must be added to
.env.example and to the relevant deployment doc.
Out of scope
- Unrelated refactors in adjacent files.
- Stylistic-only changes (formatting, renaming) that are not required by the fix.
- Anything beyond the acceptance criteria above; surface follow-ups as separate issues.
How to claim and submit
- Comment on this issue saying you'd like to take it on; wait for a maintainer to assign you (avoids duplicated effort).
- Open a PR that references this issue (
Closes #<this-issue>).
- Make sure CI is green and request review from a
CODEOWNERS maintainer.
- PRs that close this issue and pass review may qualify for a reward — see the
MAYBE REWARDED label and the FWC26 campaign page.
Category: documentation · Campaign: GrantFox OSS · Official Campaign | FWC26 · Maybe Rewarded
Summary
Description, HTTP status, and typical remediation.
Background
We rely on this information internally but it is currently tribal knowledge. Writing it down lets reviewers verify behaviour against the documented intent, lets new contributors get productive without reading every commit, and lets the support team answer common questions without paging an engineer.
Acceptance criteria
Closes #<this-issue>.Implementation hints
foo()placeholders.Repo-specific notes
npx tsc --noEmit,npm test, and the security:scan / sbom:check scripts locally before pushing..env.exampleand to the relevant deployment doc.Out of scope
How to claim and submit
Closes #<this-issue>).CODEOWNERSmaintainer.MAYBE REWARDEDlabel and the FWC26 campaign page.Category:
documentation· Campaign: GrantFox OSS · Official Campaign | FWC26 · Maybe Rewarded