Contribution Guidelines

Ediky is built and maintained by Shyama and Ayushi, so "contribution guidelines" here means two things: the standards the codebase holds itself to (so future-you and any collaborator inherit a consistent system), and the concrete rules for adding to each part of it.

Ground rules by repo

Repo	The rule
ediky-website	logic in lib/, JSX in components/, the seam is hooks/. New behavior used by two pages becomes a hook. Nothing under public/content* is hand-edited — ever
ediky_tools	content ships only through a pipeline. No hand-copying markdown into the website, no matter how small the change — the gates exist because bypassing them has shipped real bugs (duplicates, unverified solutions)
Docy	keep numeric filenames; check rendering (especially KaTeX) after pushing
ediky-core (this site)	every page states why, not just what; incidents get written into Troubleshooting; the AI index rebuilds automatically on build

Content authoring rules

1. Draft in drafts/, never directly in src/content/.
2. Structured format is mandatory — frontmatter + the section markers for that content type (see each pipeline page). The parsers are strict on purpose.
3. Kebab-case slugs, unique titles — the lint gate enforces both against live content.
4. DSA questions require the full verification set: reference solutions in C++17/Python/Java, an independent brute-force verifier, and a generator. If the brute-force diff can't be written, the question isn't specified precisely enough yet.
5. No <bits/stdc++.h> in reference solutions (production compile-timeout incident).
6. Size budgets are real — trim_oversized_cases.py and audit_sizes.py protect the sidecar economics; don't raise limits to make a problem fit, redesign the cases.

Code standards

• ESLint passes locally before push; ci.yml enforces lint + build on every push/PR anyway — don't rely on it as the first check.
• Firestore writes never contain undefined — strip/default optional fields (this was a production bug).
• New Firestore collections get: a rules block with a comment explaining the access model, an entry in Database, and a named owner hook.
• Anything touching timers, auth persistence, or the Workers' claim semantics gets read twice — those three areas encode the most subtle invariants in the system.
• Secrets: server-side env only, minimum scope, loud failure when missing. VITE_* vars are public by definition — never put a secret in one.

Commits & PRs

• Small, single-purpose commits; message says why when the diff can't.
• A change that fixes an incident links or adds the Troubleshooting entry in the same PR — the post-mortem is part of the fix.
• New VITE_* vars touch three places (.env.example, workflow pass-through, reusable workflow inputs — see Build & Deploy); the PR isn't complete until all three.

Documentation debt rule

If a change makes any page on this site wrong, updating the page is part of the change. The docs assistant answers from these pages — stale docs means a confidently wrong assistant, which is worse than no assistant.