docs(governance): add a deprecation policy for TeachLink Web

[Ajibose]

Closes #1539

Description

Adds the missing deprecation policy to the project's governance set, closing the gap noted in the issue: contributors and maintainers now have a clear, versioned reference for how TeachLink Web deprecates and removes public interfaces, user-facing capabilities, configuration, and documentation.

The change is self-contained within the Governance/ folder (two new files, nothing else touched) and contains no application-code changes, so there is no regression surface.

Type of change: Documentation update

What Was Implemented

Governance/policies/DEPRECATION.md — the deprecation policy, structured like the other governance documents (Purpose → Scope → policy sections → Ownership and Review → Success):

• Deprecation Notice Period — a minimum of one minor release cycle for user-facing capabilities and two for developer-facing interfaces (components, exports, configuration, build entry points); the clock starts at announcement in a released version, not at the decision; no deprecate-then-immediately-remove breaking changes (those are rejected or redesigned through Governance/processes/RFC_PROCESS.md); shortening allowed only for security or legal reasons, with the justification recorded in the announcement.
• Communication Channels — four mandatory channels announced in the same release that ships the deprecation: release notes (affected item, replacement, earliest release in which removal may occur), a deprecation log in the affected documentation, dev-scoped console/runtime warnings naming the replacement, and migration guidance with examples for developer-facing surfaces. Direct messages may supplement but never replace these.
• Removal Criteria — a closed list that must all hold before removal: notice period elapsed, replacement available, migration path documented, no blocking usage, auditable tracking issue exists, and removal is complete (documentation, dead configuration, redirects, and test scaffolding removed too). Removals follow the release process — never unannounced drive-by changes.

Governance/policies/DEPRECATION.test.ts — regression tests that pin the policy's enforceable guarantees (detailed below), so future edits cannot silently weaken the notice period, drop a required channel, or break governance-document conventions.

Files Changed

New files:

• Governance/policies/DEPRECATION.md — the deprecation policy
• Governance/policies/DEPRECATION.test.ts — regression tests for the policy

Modified files:

• None (scope intentionally limited to two new files inside Governance/, per the issue's acceptance criteria)

Test files:

• Governance/policies/DEPRECATION.test.ts (new, 22 tests)

Implementation Details

• The policy follows the conventions already used across Governance/ (for example domains/SITEMAP_POLICY.md, processes/RFC_PROCESS.md): # Title, then Purpose, Scope, policy sections, Ownership and Review, and Success, including the standard "changes to this policy are proposed in a pull request that touches only the Governance/ folder" rule and the ≤82-column documentation line width.
• The tests treat the policy as data: the file reads DEPRECATION.md from disk, normalizes Markdown syntax and line wrapping, and asserts on the resulting prose per ## section. Tests are deterministic (no network, no timers) and colocated with the document.
• The test file is discovered by the project's existing vitest config (**/*.test.ts), following the precedent of root-level regression tests such as next.config.cache-headers.test.ts. It is excluded from tsc and ESLint through the project's existing **/*.test.ts excludes, so type-check, lint, and build behave exactly as on main.
• The test imports only node:fs, node:path, and vitest — no application code and no mocks.

Tests Added

Governance/policies/DEPRECATION.test.ts — 22 tests, all passing:

• Document structure (5): H1 title is "Deprecation Policy"; the ordered section list matches the canonical governance layout and contains the three required areas (Deprecation Notice Period, Communication Channels, Removal Criteria); no unresolved placeholders (TBD/TODO/FIXME); line width stays within the house 82-column documentation style.
• Notice period guarantees (5): one minor release cycle for user-facing capabilities and two for developer-facing interfaces; the period starts at announcement in a release, not at the decision; breaking changes cannot be deprecated-then-removed without the RFC process; shortening is restricted to security/legal reasons and must be justified.
• Communication channel guarantees (4): all four mandatory channels are required; announcement happens in the same release that ships the deprecation; every announcement names the affected item, the replacement, and the earliest removal release; direct messages may supplement but never replace the mandatory channels.
• Removal criteria guarantees (5): the "all of the following" closed list; the six required criteria (notice period elapsed, replacement available, migration path documented, no blocking usage, tracking issue exists, removal is complete); auditable tracking issue; removal must also clean up documentation, dead configuration, and test scaffolding; unannounced drive-by removals are forbidden.
• Governance consistency (3): Governance/processes/RFC_PROCESS.md is referenced by the policy and actually exists on disk; the governance-folder-only change rule is present; the Scope section covers the surfaces that can actually be deprecated.

How to Test

pnpm install

# Run the policy regression tests:
pnpm vitest run Governance/policies/DEPRECATION.test.ts
# Expected: 22 passed (22)

# Or run the same test gate CI runs (CI skips the suite past 30s by design):
pnpm test

# Verify the other quality gates are unaffected:
pnpm run type-check
pnpm run lint

All policy tests pass; type-check and lint pass unchanged from main.

Checklist:

• Scope limited to two files, both entirely inside Governance/
• No changes made outside the Governance/ folder
• No regression in existing functionality (documentation plus a standalone test file only)
• Tests pass; type-check and lint pass
• Change is documented in this PR description

[drips-wave]

@Ajibose 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.