chore: align repository governance

.github/CONTRIBUTING.md

@@ -106,35 +106,20 @@ adding the file on disk alone compiles nothing and reports no error.
 
 ## Pull requests
 
-Write the description as prose about the change, not a log of your afternoon.
-The three things a reviewer needs:
-
-1. **What changed**, in a sentence or two.
-2. **Why this way** — the mechanism behind the old behaviour, and what makes
-   this the right place to fix it. `WKWebView`, AppKit window levels and
-   Spaces all have defaults that surprise people; naming the one you hit is
-   usually the most useful sentence in the whole description.
-3. **What you traded away** — what you left alone on purpose, what you're
-   unsure about, which macOS versions or display setups you couldn't test.
-
-Stating the gaps is worth more than a description with no gaps in it. Nobody
-has every display configuration.
-
-The pull request template has these as headings. Delete the ones that don't
-apply.
-
-Small and focused beats large and complete. If you find a second problem while
-fixing the first, mention it in the description or open an issue — a pull
-request that does one thing gets reviewed; one that does four gets postponed.
-
-**Write commit messages, pull requests and issues in English.** Not because
-English is better, but because it is the one language everyone reading this
-repository has in common, and a commit message is read by whoever runs
-`git blame` on the line they are about to change — years later, by someone the
-author will never meet. The message is where the reasoning lives; a reader who
-cannot read it gets the diff and nothing else.
-
-Say why, not what. The diff already says what changed.
+Use the [PR template](PULL_REQUEST_TEMPLATE.md): a short summary, verification
+and issue links. Explain the cause and tradeoff when they help review; do not
+repeat the diff. Keep each PR focused on one reviewable change.
+
+Record the commands and results, relevant macOS/hardware and any untested paths.
+For site submissions, describe the site and settings; app-specific checks are
+only relevant when app code changes.
+
+Use `Closes #123` or `Fixes #123` when the PR completes an issue. For partial
+work, use `Related to #123` and state what remains. Completed issues close on
+merge; there is no release-confirmation or inactivity-close bot.
+
+Write commit messages, pull requests and issues in English. Repository settings
+and label conventions are documented in [Governance](GOVERNANCE.md).
 
 ## Relationship to Plash
 

.github/GOVERNANCE.md

@@ -0,0 +1,38 @@
+# Repository governance
+
+Adopted baseline: **2026-09-16** from [PathGao/governance](https://github.com/PathGao/PathGao/tree/main/governance).
+Adopted [source snapshot](https://github.com/PathGao/PathGao/tree/efab3e421c6606c1ce0a1c5836e98ba0ff64addb/governance).
+Updates are reviewed and copied manually; there is no automatic inheritance.
+
+## Workflow
+
+Use the short PR template. `Closes #123` or `Fixes #123` closes a completed issue
+on merge. For partial work, use `Related to #123` and state what remains. There
+is no release-confirmation or inactivity-close automation.
+
+`question` is a usage question. `needs info` waits for reporter details,
+`awaiting decision` waits for a maintainer decision, and `planned` means accepted.
+Type and resolution labels are defined in [labels.json](labels.json).
+
+## Maintenance
+
+[settings.json](settings.json) and [rulesets/](rulesets/) are desired GitHub
+configuration, applied through the API as described in the baseline guide.
+Committing these files alone does not change repository settings. Main requires
+PRs and blocks deletion/force pushes; administrators retain a recovery bypass.
+Release tags matching `v*` cannot be updated/deleted, except `v*-test*` tags.
+
+Preview label changes from the repository root:
+
+```sh
+./Tools/sync-labels.sh PathGao/Nifro
+```
+
+Add `--apply` to create/update the declared labels. Labels outside the manifest
+are preserved, including historical labels attached to closed issues.
+
+## Project differences
+
+Nifro retains site submission and other project labels, existing issue forms,
+and its five required CI jobs. `Final_Check_Request` remains only as a legacy
+GitHub label for historical issues; it is outside the managed manifest.

.github/ISSUE_TEMPLATE/config.yml

@@ -1 +1,5 @@
 blank_issues_enabled: true
+contact_links:
+  - name: Security vulnerability
+    url: https://github.com/PathGao/Nifro/security/advisories/new
+    about: Report vulnerabilities privately.

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,51 +1,13 @@
-<!--
-Nothing below is required. These are the sections a useful pull request here
-tends to have, offered so you don't have to reverse-engineer them. Delete any
-that don't apply, rename them to say what you actually found, and write prose
-rather than filling in fields.
+<!-- Keep this short. Delete sections that do not apply. -->
 
-Adding a site to sites/? Only "What this is" matters — say what the site is and
-what settings you used, and ignore the rest.
--->
+## Summary
 
-## What this is
-
-What changes, and `Closes #123` if there's an issue. If someone reported it,
-say who and where.
-
-## Mechanism
-
-Why the old behaviour happened — the specific line, default or assumption
-responsible — rather than what you did about it. `WKWebView`, AppKit window
-levels and Spaces all have defaults that surprise people, so naming the one
-you hit is the most valuable part of the description. If you measured
-something, paste the numbers.
-
-## Scope
-
-What you deliberately left alone, and why. Anything you noticed while working
-and chose not to fix here belongs in this section too. A small fix plus a note
-about the larger problem is easier to review, and easier to revert, than both
-at once.
+<!-- What changes? For a fix, describe the problem. Add the mechanism or tradeoff only when it helps review. -->
 
 ## Verification
 
-`swift test` covers the pure logic — the crop and zoom geometry, the menu bar strip, schedule
-windows, which website is current on which display, video embedding and URL commands. Anything that
-needs a window server or a web view has no automated coverage at all, so say what you ran by hand.
-
-- Which macOS version and hardware you ran it on.
-- The websites you tried it against, by URL.
-- Whether you tested with more than one display, and with browsing mode both
-  on and off, if your change goes anywhere near either.
-- That `swiftlint` passed — it runs as a build phase, so a clean build is
-  enough.
-
-And what you *didn't* verify: macOS versions or hardware you couldn't try,
-paths you reasoned about rather than ran. That's more useful to a reviewer
-than a list with no gaps in it.
+<!-- Commands and results, relevant hardware/macOS, and anything not tested. Add before/after images for visible changes. -->
 
-## Screenshots
+## Issues
 
-For anything visible, before and after. Drag images straight into the
-description.
+<!-- Use Closes #123 or Fixes #123 when this PR completes the issue. For partial work, use Related to #123 and state what remains. -->

.github/SECURITY.md

@@ -8,9 +8,9 @@ rather than as a public issue. That form is the only channel — there is one
 maintainer and no security mailing list, and a public issue for a live
 vulnerability is the one thing that cannot be undone.
 
-Expect a first reply within a week. If a report holds up, the fix ships in the
-next release and the advisory is published with it, crediting you unless you
-ask otherwise.
+Security fixes target the latest release. Give the maintainer time to investigate
+and ship a fix before public disclosure; reporters can request credit. This
+community project does not promise a response time.
 
 ## What is in scope
 
@@ -35,9 +35,12 @@ their windows. The interesting boundary is between that page and the machine:
   app runs pages the user chose, with the JavaScript the user pasted; that is
   the feature.
 - Anything that requires the attacker to already have the user's account.
-- Gatekeeper warnings on directly downloaded builds. That is expected and
-  documented in [docs/RELEASE.md](../docs/RELEASE.md) — builds are self-signed and
-  not notarized. Homebrew is the supported route.
+
+## Release integrity
+
+Official releases from v0.9.1 use Apple Developer ID signing and notarization.
+Report unexpected signature, notarization or artifact-integrity failures with
+the download source and exact system message. See [the release guide](../docs/RELEASE.md).
 
 ## Supported versions
 

.github/labels.json

@@ -0,0 +1,92 @@
+[
+  {
+    "name": "bug",
+    "color": "d73a4a",
+    "description": "Something isn't working"
+  },
+  {
+    "name": "enhancement",
+    "color": "a2eeef",
+    "description": "New feature or improvement"
+  },
+  {
+    "name": "documentation",
+    "color": "bfd4f2",
+    "description": "Docs, README or contributor-facing text"
+  },
+  {
+    "name": "question",
+    "color": "fbca04",
+    "description": "A usage question, not a request for missing information"
+  },
+  {
+    "name": "needs info",
+    "color": "f9d0c4",
+    "description": "Waiting on the reporter to supply missing information"
+  },
+  {
+    "name": "awaiting decision",
+    "color": "c129c4",
+    "description": "Needs a maintainer decision before work can start"
+  },
+  {
+    "name": "planned",
+    "color": "0453ab",
+    "description": "Accepted and queued for work"
+  },
+  {
+    "name": "duplicate",
+    "color": "cfd3d7",
+    "description": "Same issue or pull request; link to the original"
+  },
+  {
+    "name": "wontfix",
+    "color": "6e7781",
+    "description": "Decided against, with a reason"
+  },
+  {
+    "name": "dependencies",
+    "color": "b9d130",
+    "description": "Dependency update"
+  },
+  {
+    "name": "github_actions",
+    "color": "000000",
+    "description": "GitHub Actions update"
+  },
+  {
+    "name": "accessibility",
+    "color": "f143ab",
+    "description": "Barrier affecting people with disabilities"
+  },
+  {
+    "name": "good first issue",
+    "color": "7057ff",
+    "description": "Good for newcomers"
+  },
+  {
+    "name": "help wanted",
+    "color": "008672",
+    "description": "Extra attention is needed"
+  },
+  {
+    "name": "invalid",
+    "color": "e4e669",
+    "description": "This doesn't seem right"
+  },
+  {
+    "name": "site submission",
+    "color": "1D76DB",
+    "description": "A page proposed for the curated site list"
+  },
+  {
+    "name": "swift",
+    "color": "F05138",
+    "description": "Pull requests that update Swift code"
+  },
+  {
+    "name": "upstream",
+    "color": "E4E669",
+    "description": "The cause is in WebKit, macOS or the site itself, not in Nifro"
+  }
+]