docs: establish contribution and product foundations

.github/ISSUE_TEMPLATE/bug.yml

@@ -0,0 +1,35 @@
+name: Bug
+description: Something is not working
+labels: [bug]
+body:
+  - type: markdown
+    attributes:
+      value: "**Security problem?** Do not use this form — follow the private reporting instructions in [SECURITY.md](https://github.com/SDOC-Team/devnepal/blob/main/SECURITY.md)."
+  - type: textarea
+    id: what-happens
+    attributes: { label: What happens }
+    validations: { required: true }
+  - type: textarea
+    id: expected
+    attributes: { label: What should happen }
+    validations: { required: true }
+  - type: textarea
+    id: steps
+    attributes:
+      label: Steps to reproduce
+      value: |
+        1.
+        2.
+    validations: { required: true }
+  - type: dropdown
+    id: language
+    attributes:
+      label: Language
+      options: ["English", "नेपाली", "Both"]
+  - type: input
+    id: environment
+    attributes:
+      label: Browser and device
+  - type: markdown
+    attributes:
+      value: "Please do not include real personal data, credentials, or production records."

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,8 @@
+blank_issues_enabled: true
+contact_links:
+  - name: Report a security vulnerability
+    url: https://github.com/SDOC-Team/devnepal/blob/main/SECURITY.md
+    about: Never report security issues publicly. Check the policy for private reporting availability
+  - name: Code of conduct concern
+    url: https://github.com/SDOC-Team/devnepal/blob/main/CODE_OF_CONDUCT.md
+    about: Check the policy for private contact availability. Do not post confidential reports in public issues

.github/ISSUE_TEMPLATE/design.yml

@@ -0,0 +1,35 @@
+name: Design or accessibility
+description: Propose an interface improvement or report an accessibility problem
+labels: [design]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Icons, accessibility fixes, typography and content are open now.
+        The core visual language is being settled by the design team — we will open it once the design system is published.
+  - type: textarea
+    id: problem
+    attributes:
+      label: What is the problem for a user?
+    validations: { required: true }
+  - type: textarea
+    id: existing
+    attributes:
+      label: Which existing pattern is inadequate, and why?
+  - type: textarea
+    id: proposal
+    attributes:
+      label: Proposal
+      description: Screenshot, link, or description.
+    validations: { required: true }
+  - type: textarea
+    id: bilingual
+    attributes:
+      label: How does this work in both languages?
+      description: Required. Devanagari has different line-height and width behaviour from Latin.
+    validations: { required: true }
+  - type: textarea
+    id: a11y
+    attributes:
+      label: Accessibility
+      description: Keyboard operation, focus order, contrast.

.github/ISSUE_TEMPLATE/task.yml

@@ -0,0 +1,53 @@
+name: Task
+description: A well-scoped piece of work ready for a contributor
+body:
+  - type: textarea
+    id: context
+    attributes:
+      label: Context
+      description: Two to four sentences. Why does this exist, who does it serve? Assume no prior knowledge of this project.
+    validations: { required: true }
+  - type: textarea
+    id: in-scope
+    attributes:
+      label: In scope
+    validations: { required: true }
+  - type: textarea
+    id: out-of-scope
+    attributes:
+      label: Out of scope
+      description: Be explicit. This field prevents most oversized pull requests and protects your time.
+    validations: { required: true }
+  - type: textarea
+    id: acceptance
+    attributes:
+      label: Acceptance criteria
+      value: |
+        - [ ]
+        - [ ]
+    validations: { required: true }
+  - type: textarea
+    id: where
+    attributes:
+      label: Where to look
+      description: Files and modules involved, and an existing example to copy the pattern from.
+    validations: { required: true }
+  - type: textarea
+    id: tests
+    attributes:
+      label: Tests expected
+      description: Describe automated tests or manual verification. If none apply, explain why.
+    validations: { required: true }
+  - type: dropdown
+    id: size
+    attributes:
+      label: Size
+      options: ["S — under 4 hours", "M — 4 to 16 hours", "L — 16 to 40 hours"]
+    validations: { required: true }
+  - type: input
+    id: mentor
+    attributes:
+      label: Mentor
+      description: Who will answer questions on this issue
+      placeholder: "@username"
+    validations: { required: true }

.github/ISSUE_TEMPLATE/translation.yml

@@ -0,0 +1,27 @@
+name: Nepali translation or content
+description: Improve Nepali wording, terminology, or English microcopy
+labels: [i18n, nepali-language]
+body:
+  - type: markdown
+    attributes:
+      value: "This is one of the most valuable kinds of contribution here, and it needs no code."
+  - type: input
+    id: where
+    attributes:
+      label: Where is it?
+      placeholder: "Page, or the string key"
+    validations: { required: true }
+  - type: textarea
+    id: current
+    attributes: { label: Current wording }
+    validations: { required: true }
+  - type: textarea
+    id: suggested
+    attributes: { label: Suggested wording }
+    validations: { required: true }
+  - type: textarea
+    id: why
+    attributes:
+      label: Why is this better?
+      description: Register, accuracy, clarity, or common usage.
+    validations: { required: true }

.github/pull_request_template.md

@@ -18,3 +18,10 @@
 ## Notes for reviewers
 
 <!-- Anything reviewers should pay extra attention to. -->
+
+## Foundation checklist
+
+- [ ] Commits signed off (`git commit -s`)
+- [ ] Works in **both** English and Nepali where applicable
+- [ ] No secrets or real personal data anywhere in the diff
+- [ ] Documentation updated; English and Nepali versions agree where both exist

.gitignore

@@ -36,3 +36,5 @@ coverage/
 # Agent instructions that `next dev` regenerates
 /apps/api/AGENTS.md
 /apps/api/CLAUDE.md
+.claude/
+.codex/

CODE_OF_CONDUCT.md

@@ -0,0 +1,59 @@
+# Code of Conduct
+
+## Our commitment
+
+devNepal is a public space serving the people of Nepal. Everyone participating is entitled to a harassment-free experience regardless of background, identity, experience level, employment status, or first language.
+
+---
+
+## Expected
+
+- Treat people with respect, including — especially — in disagreement
+- Assume good faith. Ask before assuming error
+- Welcome first-time contributors. Everyone was one
+- Accept review feedback gracefully, and give it kindly
+- Respect that English is not everyone's first language, and that Nepali is not everyone's either
+
+---
+
+## Not acceptable
+
+- Harassment, intimidation, or discriminatory language
+- Personal or political attacks
+- Publishing another person's private information
+- Sustained disruption of discussion
+- **Impersonating another person or organisation**, including claiming an affiliation you do not hold
+- Unwelcome attention of any kind
+
+---
+
+## Reporting
+
+**Private reporting contact:** not yet published. Do not put confidential reports in public issues.
+
+We will:
+
+- Acknowledge within 48 hours
+- Keep the report confidential, sharing only with those who need to act
+- Tell you what action was taken
+
+**You will never be penalised for a good-faith report**, including a report about a maintainer or a government team member.
+
+---
+
+## Enforcement
+
+In proportion, and always with a recorded reason:
+
+1. **Private correction** — a clarification of what was expected
+2. **Public warning**
+3. **Temporary suspension** from participation
+4. **Permanent ban**
+
+Decisions may be appealed privately and must be reviewed by someone not involved in the original decision. An appeal contact has not yet been published.
+
+---
+
+## Scope
+
+This applies to this repository, the devNepal portal, and any space where someone is representing the project.

CONTRIBUTING.md

@@ -0,0 +1,113 @@
+# Contributing to devNepal
+
+Thank you. This is a public service built in public, and outside contribution is the point rather than a bonus.
+
+**This page explains how we work together.** Branch names, commit format, labels, and the checklists for a ready issue and a finished pull request are in **[docs/CONVENTIONS.md](./docs/CONVENTIONS.md)** — read it once, then look things up as you need them.
+
+---
+
+## What we commit to
+
+| | |
+|---|---|
+| First response to a pull request or issue | **Within 3 days** |
+| Security report acknowledgement | **Within 24 hours** |
+
+Days are calendar days. Most of us do this outside a day job, so review happens in short windows through the week plus one longer session at the weekend.
+
+If we are ever at capacity we will say so publicly and pause new claims, rather than going quiet.
+
+---
+
+## Before you start
+
+**Only claim issues labelled `ready`. Comment on the issue to claim it.** We will assign it to you. If nothing suitable is ready, open a proposal or ask for clarification before starting.
+
+After 14 days without activity, maintainers will check in and may manually unassign the issue, leaving an explanation. This is never a judgement on you — claim it again whenever you are ready.
+
+**Open an issue before large or design work.** A proposal that arrives as a finished artifact has already cost you a weekend, and we would rather agree the problem with you first.
+
+---
+
+## How to contribute code
+
+1. Fork the repository, branch from `main`
+2. Make your change. **One issue per pull request**
+3. **Sign off every commit**: `git commit -s`
+4. Open a pull request referencing the issue
+
+Branch naming, commit message format and pull-request size guidance are in **[docs/CONVENTIONS.md](./docs/CONVENTIONS.md)**.
+
+Draft pull requests are welcome early. Reviewing direction at 20% complete costs everyone less than reviewing at 100%.
+
+---
+
+## Sign-off (DCO)
+
+Every commit needs a `Signed-off-by` line, which `git commit -s` adds from your git configuration. Use `-s` on every commit.
+
+It certifies that you wrote the contribution, or that you have the right to submit it under this project's licence. It is **not** a copyright assignment — you keep the copyright in your work, and there is no separate agreement to sign.
+
+Full text: <https://developercertificate.org>
+
+---
+
+## Licensing
+
+devNepal is released under the Apache License 2.0. By submitting a contribution you agree it is licensed to the project under those same terms.
+
+You retain copyright in your contribution. We do not ask you to assign or transfer it.
+
+---
+
+## Contribution is not only code
+
+Design, Nepali translation, documentation, testing, accessibility and security work are all reviewed and credited the same way as code. If you want to contribute to an area not on that list, open an issue and ask — the list grows as the people who can review it arrive.
+
+If you improve a Nepali error message or find a contrast failure, you have contributed. Tell us and we will credit it.
+
+**On design work specifically:** The core visual language is being settled by the design team while the system is established — we will say so when that changes.
+
+---
+
+## What we look for
+
+- Works in **both** English and Nepali
+- Accessible: keyboard operable, visible focus, sufficient contrast
+- Uses design tokens — never hard-coded colours or spacing
+- Tests for behaviour changes
+- **No new dependency without agreeing it in the issue first.** This is a government supply chain
+
+The full definition of done, and what makes an issue safe to claim, are in [docs/CONVENTIONS.md](./docs/CONVENTIONS.md).
+
+---
+
+## Review
+
+Reviews name the specific change requested, never a vague dissatisfaction.
+
+A comment prefixed `Nit:` is a preference and never blocks a merge.
+
+**If we decline a pull request on direction, we will explain what would have been accepted.** You spent hours; three sentences of explanation is the minimum owed.
+
+If we take over a pull request, you keep the credit and we will tell you why.
+
+---
+
+## Security
+
+**Never report a vulnerability in a public issue or pull request.** See [SECURITY.md](./SECURITY.md).
+
+If you find a security problem while working on something unrelated, stop and report it privately. A public fix is a public disclosure.
+
+---
+
+## Language
+
+Issues, pull requests and reviews may be in English or Nepali. Say so if you would prefer Nepali and we will switch.
+
+---
+
+## Who merges
+
+Maintainers — who may be from outside government — review and approve. **Merge and deployment are performed by the government team.** This is a deliberate boundary, described in [GOVERNANCE.md](./GOVERNANCE.md).

GOVERNANCE.md

@@ -0,0 +1,37 @@
+# Governance
+
+## The short version
+
+**The government department that owns a system decides what it must do. The technical team decides how it is built. The community contributes the work and the scrutiny. Merge and deployment are government-only.**
+
+---
+
+## Roles
+
+| Role | Who | Decides | Does not decide |
+|---|---|---|---|
+| **Steering** | Office of the Prime Minister | Which projects enter the devNepal programme; funding; approval to deploy to production | What any individual system must do; technical design; individual pull requests |
+| **Sponsoring department** | The ministry or body that owns a given system. **For this portal, the Office of the Prime Minister** | What that system must do; acceptance of completed work | How it is built; who may contribute; when it deploys |
+| **Core team** | Government-employed or contracted engineers | Architecture, stack, merge, release, deployment, security posture | What a system must do |
+| **Maintainers** | Appointed by the core team, **and may be from outside government** | Review and approval of pull requests in their area; triage; mentoring | Merge to `main`; deployment; releases |
+| **Contributors** | Anyone | What they work on, from the open backlog | — |
+
+---
+
+## Maintainers, and how you become one
+
+
+| Level | Who | What they can do |
+|---|---|---|
+| **Contributor** | Anyone | Propose changes, comment, review informally |
+| **Maintainer** | Appointed by the core team. **May be from outside government** | Binding approval of pull requests in their area |
+| **Core** | Government appointment or contract | Merge, release, deploy |
+
+
+**What comes next.** Once there is a body of contributors with a real track record, we will publish criteria for moving from contributor to maintainer — a promotion path, rather than appointment — and start promoting from contribution. The criteria will be stated plainly rather than left to judgement.
+
+**What holds regardless:**
+
+- Maintainers may be non-government. **Nobody outside government merges or deploys**
+- Authority is area-scoped — a maintainer of the design system has no authority over authentication
+- We would rather give you review authority than keep reviewing everything ourselves. If you are contributing consistently in one area, ask where you stand and we will tell you plainly