docs(governance): add Code of Conduct, reporting process, enforcement ladder and stale issue policy

[ThatCodeBabe]

Closes #1591
Closes #1592
Closes #1593
Closes #1606

Four governance gaps, one per issue, each a single new file inside Governance/.

Issue	File	Covers
#1591	Governance/CODE_OF_CONDUCT.md	Expected behaviour · unacceptable behaviour · scope
#1593	Governance/COC_REPORTING.md	Reporting channel · response timeline · confidentiality
#1592	Governance/COC_ENFORCEMENT.md	Graduated steps · criteria for each · who applies them
#1606	Governance/policies/STALE_ISSUES.md	Staleness threshold · warning and closing steps · reopen path

---

CODE_OF_CONDUCT.md — #1591

CONTRIBUTING.md §1 carried the entire conduct standard in one paragraph, and COC_APPEALS.md §1 already referred to "the project's Code of Conduct" as though it were a document — it was not one. This is that document, and CONTRIBUTING.md §1 now reads as its summary.

Beyond the required sections it adds an explicit "what is not a violation" table. A Code of Conduct that gets read as forbidding firm technical disagreement stops being used, so rejecting a PR, disagreeing with a maintainer in public, and closing an issue as out of scope are named as not violations. The distinction throughout is conduct toward people, not positions on technical questions.

The scope section also draws the off-project boundary deliberately: unrelated personal or political activity is out of scope, but harassment that follows someone out of the repository because of what happened in it is in scope, because its effect lands inside the project.

Adapted from Contributor Covenant 2.1, with the scope boundaries, the abuse-of-position and retaliation provisions, and the not-a-violation list added for this project.

COC_REPORTING.md — #1593

The three required elements, plus the cases a reporting process actually fails on:

• Reporting a maintainer or the project lead — report to any other maintainer; a report is never handled by its subject, and if every maintainer is conflicted the matter goes to the steering group or an external reviewer.
• Anonymous reports — accepted, with the two consequences stated plainly rather than glossed: no follow-up questions, and no outcome notification.
• Provisional protective measures — available before a review concludes, explicitly not a finding, time-boxed, and appealable.

The confidentiality section commits to six specific things and then states the limits honestly — physical-safety risk and legal obligation — because a guarantee with unstated exceptions is worse than a narrower one.

The timeline is 2 business days to acknowledge, 5 to assign an unconflicted handler, 21 calendar days to decide, extendable once by 14 days with a stated reason. A deadline missed by the project never shortens the reporter's appeal window.

COC_ENFORCEMENT.md — #1592

A five-step ladder, each step carrying its criteria, the authority required, and a stated duration:

Step	Duration	Decided by
1 — Private correction	—	Any maintainer
2 — Formal warning	12 months on record	Maintainer + one consulted
3 — Temporary restriction	7–90 days	Two maintainers
4 — Suspension	30 days–12 months	Maintainer team by quorum
5 — Permanent ban	Indefinite	Maintainer team by quorum, never one person

Why a published scale matters here specifically: COC_APPEALS.md §5.1 already lets a sanction be appealed as disproportionate, and that ground is unusable without a scale to measure against. This supplies it.

§4 records what moves a response up or down — severity, repetition, ongoing risk, abuse of position, retaliation (step 4 minimum, because it attacks the reporting process everything else depends on), and impact on a newer contributor — along with the mitigating factors, and which conduct mitigation does not apply to. §6 sets expiry windows so a sanction stops counting toward escalation after a stated period.

policies/STALE_ISSUES.md — #1606

Written as the counterpart to the existing STALE_PRS.md and in the same format.

60 days, not 30. processes/TRIAGE.md and the status: stale definition in LABEL_TAXONOMY.md both already say 60 for issues, while STALE_PRS.md uses 30 for pull requests. This policy keeps 60 and explains the difference rather than leaving it looking like an inconsistency: a PR rots on its own — the branch drifts, conflicts accumulate, review context fades — whereas a bug nobody has reached is still a bug after two months. The document notes that all three places must change together if the threshold is ever revised.

Two choices worth a look:

• Closed as not planned, never as completed. Closing an unfixed bug as completed corrupts the project's own history and any metrics drawn from it.
• Anyone may reopen by commenting — no new issue, no justification, no maintainer permission. The exemption table also keeps priority: high/critical out of auto-closure entirely, since sustained inactivity there is a triage failure rather than something closing the issue fixes.

---

Scope and verification

• Documentation only. No code, no configuration, no dependency, no application behaviour.
• Entirely within Governance/. git status shows four added files and nothing else.
• No regression possible. lint, format:check and the jest suites all target .ts under src/, test/, apps/ and libs/; nothing in this PR is within their globs.
• All 86 relative links in the four documents were checked and resolve, including the cross-references into COC_APPEALS.md, REVOCATION.md, QUORUM.md, TRANSPARENCY_REPORTS.md, LABEL_TAXONOMY.md, TRIAGE.md and roles/MAINTAINER.md.
• Each document carries its own metadata block and change log, matching whichever house style its nearest neighbour uses — COC_APPEALS.md for the three conduct documents, STALE_PRS.md for the stale issue policy.

One note: the contact address in COC_REPORTING.md is conduct@teachlink.example, following the same placeholder convention as security@teachlink.example in SECURITY_POLICY.md, and flagged in the document for replacement with the real address. Happy to substitute it if you tell me what it should be.

I kept Governance/README.md untouched: its index is already behind the folder's current contents, and updating it here would collide with other open governance PRs. It looks like it wants one PR of its own to resync — glad to do that separately if useful.

[drips-wave]

@ThatCodeBabe Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[RUKAYAT-CODER]

Thank you for contributing to the project