Sync contributing/security/issue templates

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,35 @@
+---
+name: Bug report
+about: Something isn't working as expected
+title: ''
+labels: bug
+assignees: ''
+---
+
+## Repo / area
+
+<!-- Which repo, and which part of it (e.g. "redduck-landing-p, contact form"). -->
+
+## Description
+
+<!-- What's wrong? -->
+
+## Steps to reproduce
+
+1.
+2.
+3.
+
+## Expected behavior
+
+<!-- What you expected to happen. -->
+
+## Actual behavior
+
+<!-- What actually happened. Include error messages/screenshots if relevant. -->
+
+## Environment
+
+- Browser / Node version:
+- Package manager + version (`npm -v` / `pnpm -v`):
+- OS:

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1 @@
+blank_issues_enabled: false

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,23 @@
+---
+name: Feature request
+about: Suggest an idea or improvement
+title: ''
+labels: enhancement
+assignees: ''
+---
+
+## Repo / area
+
+<!-- Which repo does this apply to? -->
+
+## Problem
+
+<!-- What's the problem or gap? What can't you do today? -->
+
+## Proposed solution
+
+<!-- What you'd like to see happen. -->
+
+## Alternatives considered
+
+<!-- Other approaches you thought about, and why you didn't go with them. -->

CODE_OF_CONDUCT.md

@@ -0,0 +1,63 @@
+# Contributor Covenant Code of Conduct
+
+This is the org-wide default. It applies to any RedDuckTeam repository that
+doesn't have its own `CODE_OF_CONDUCT.md`.
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic
+status, nationality, personal appearance, race, religion, or sexual identity
+and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment:
+
+- Demonstrating empathy and kindness toward other people.
+- Being respectful of differing opinions, viewpoints, and experiences.
+- Giving and gracefully accepting constructive feedback.
+- Accepting responsibility for mistakes, apologizing, and learning from them.
+- Focusing on what is best for the community as a whole.
+
+Examples of unacceptable behavior:
+
+- The use of sexualized language or imagery, and unwelcome sexual attention.
+- Trolling, insulting or derogatory comments, and personal or political attacks.
+- Public or private harassment.
+- Publishing others' private information without explicit permission.
+- Other conduct which could reasonably be considered inappropriate in a
+  professional setting.
+
+## Enforcement Responsibilities
+
+Maintainers are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior they deem inappropriate, threatening, offensive, or
+harmful.
+
+## Scope
+
+This Code of Conduct applies within all community spaces (issues, pull
+requests, discussions) and also applies when an individual is officially
+representing the community in public spaces.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to [contact@redduck.io](mailto:contact@redduck.io). All complaints
+will be reviewed and investigated promptly and fairly.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.1, available at
+[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
+
+[homepage]: https://www.contributor-covenant.org
+[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html

CONTRIBUTING.md

@@ -0,0 +1,86 @@
+# Contributing
+
+Thanks for helping build RedDuck's work. This is the org-wide default and
+applies to any RedDuckTeam repository without its own `CONTRIBUTING.md` — a
+repo's own copy always wins over this one.
+
+## Local setup
+
+The package manager varies by repo (some use `pnpm`, some use `npm`) — check
+the repo's `package.json` (`packageManager` field) or its README before
+running anything. In general:
+
+```bash
+<pnpm|npm> install
+cp .env.example .env   # if the repo has one
+<pnpm|npm> run dev
+```
+
+## Before opening a PR
+
+Run whichever of these scripts exist in the repo — most have all four, some
+have a subset:
+
+```bash
+<pm> run lint
+<pm> run typecheck
+<pm> run build
+<pm> run test
+```
+
+A PR shouldn't be opened with a failing check. If CI is configured for the
+repo, it re-runs the same checks — don't rely on CI to catch what you could
+catch locally first.
+
+## Before you start on something non-trivial
+
+Open an issue and get a nod first — don't spend real time on a new feature
+or a non-obvious fix before it's been discussed. This isn't process for its
+own sake: it's the difference between a PR that merges same-day and one
+that sits because the approach needed to change. Small fixes and obvious
+bugs don't need this — use judgment.
+
+## Git, commits, and PRs
+
+- **Commits are informative.** Not `feat: almost completed` or `fix: stuff`.
+  A commit message should say what changed and, where it's not obvious, why.
+- **Never commit broken code.** Each commit is a real, working snapshot. If
+  you need to push work-in-progress to remote as a backup, push it to its own
+  branch — don't land it on the branch others will build on.
+- **Split commits reasonably.** Prefer several focused commits
+  (`git add -p` is useful here) over one large commit that bundles unrelated
+  changes.
+- **No dead code, no `old/`, no `archive/`.** Git already keeps full history —
+  commented-out code and "just in case" folders don't need to live in the
+  tree. Delete it; it's recoverable from history if it's ever actually needed.
+- **Merge only when the branch is actually done.** Don't merge early just to
+  hand off a partial fix to someone else — use `git cherry-pick` (or just ask)
+  instead of merging an unfinished branch into a shared one. Opening a PR
+  early for visibility or feedback is fine — mark it a **draft** so it's
+  clear it isn't ready to merge yet; that's a different thing from merging
+  unfinished work.
+- **Refactor for a reason, not for taste.** A drive-by rewrite of working
+  code because it "reads better" your way creates a large diff with no
+  behavior change and makes history harder to trace. Refactor when it's
+  needed for the fix or feature at hand, or file it as its own separate PR
+  with a concrete justification (perf, a bug it enables fixing, etc.) —
+  don't bundle it into an unrelated change.
+- **Before solving something from scratch, check if it's already been solved.**
+  If the task is something the industry (or another RedDuck repo) has already
+  built many times over — wallet connection, KYC integration, a common DeFi
+  primitive — look at how it's usually done first. Re-deriving a well-trodden
+  pattern from zero is rarely the best use of the time.
+
+## Code review
+
+Before requesting review, check your own change against the task/ticket it's
+solving and give it a self-review pass — most review cycles that go back and
+forth repeatedly are cases where this step got skipped. From there: automated
+checks (lint/typecheck/build/test) run first, then a human review. Don't
+merge your own PR unless the repo's process explicitly allows it.
+
+## Security-sensitive changes
+
+If your change touches wallet connections, signing, token approvals,
+contract interaction, or anything else that could move funds or grant
+approvals, see [SECURITY.md](SECURITY.md) before opening the PR.

PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,28 @@
+# Pull Request
+
+## What changed
+
+<!-- Describe the change and why it's needed. New feature or non-obvious fix? Consider opening an issue to discuss the approach first — it merges faster than a PR that needs to change direction mid-review. -->
+
+Fixes #___ <!-- delete this line if there's no issue -->
+
+## Type of change
+
+- [ ] Bug fix
+- [ ] New feature
+- [ ] Refactor / cleanup (no behavior change)
+- [ ] Docs
+- [ ] Chore / tooling / CI
+
+## Screenshots
+
+<!-- If this touches UI, add a before/after. Delete this section if not applicable. -->
+
+## Checklist
+
+- [ ] `lint` / `typecheck` / `build` / `test` pass locally (whichever scripts exist in this repo)
+- [ ] No `.env`, secrets, `node_modules`, or build output committed
+
+## Security-sensitive?
+
+<!-- If this touches wallet connection, signing, approvals, or contract interaction, say so here and see SECURITY.md. Delete this section if not applicable. -->

SECURITY.md

@@ -0,0 +1,34 @@
+# Security Policy
+
+A contract or a signing flow ships once and can hold real money — this is the
+org-wide default policy for handling that responsibly, and it applies to any
+RedDuckTeam repository without its own `SECURITY.md`.
+
+## Reporting a Vulnerability
+
+Please report security issues privately through GitHub Security Advisories on
+the specific repository, rather than opening a public issue. If advisories
+aren't enabled yet on that repo, contact the maintainers privately before
+publishing any details.
+
+Note: enabling private vulnerability reporting is a separate, per-repository
+setting (Settings → Security → Private vulnerability reporting) — this file
+existing doesn't turn it on by itself.
+
+## Scope
+
+Security-sensitive areas across RedDuck repos typically include:
+
+- Wallet connection and signing flows.
+- Token approval, allowance, and spender logic.
+- Contract interaction and calldata generation.
+- Address, amount, and recipient parsing.
+- Transaction simulation and gas-limit checks.
+- Anything that could redirect funds, approvals, or private data.
+
+## Important Notes
+
+Most of these repos are actively developed applications, not versioned
+libraries — treat `main` as the only supported branch. Templates and demos in
+this org are not necessarily audited; check the specific repo's README before
+using it with real funds or in production.