ci(lint): adopt the canonical org lint gate

.editorconfig

@@ -0,0 +1,40 @@
+# EditorConfig — https://editorconfig.org
+# Keeps whitespace consistent across editors and IDEs before
+# Prettier / rustfmt / ruff get a chance to run.
+
+root = true
+
+[*]
+charset = utf-8
+end_of_line = lf
+indent_style = space
+indent_size = 2
+trim_trailing_whitespace = true
+insert_final_newline = true
+
+[*.md]
+# Markdown: trailing spaces are significant (hard line-break).
+# Let Prettier handle wrapping; don't trim here.
+trim_trailing_whitespace = false
+
+[*.{yml,yaml}]
+indent_size = 2
+
+[*.{json,jsonc}]
+indent_size = 2
+
+[*.toml]
+indent_size = 4
+
+[Makefile]
+indent_style = tab
+
+[*.rs]
+# rustfmt handles Rust formatting; EditorConfig just sets the baseline.
+indent_size = 4
+
+[*.py]
+indent_size = 4
+
+[*.{cpp,cc,c,h,hpp}]
+indent_size = 4

.github/PULL_REQUEST_TEMPLATE.md

@@ -16,8 +16,8 @@
 
 ## Commits
 
-- [ ] Each commit is a coherent step with a message that says *why*, not
-      just *what*. They are not going to be squashed away.
+- [ ] Each commit is a coherent step with a message that says _why_, not
+      just _what_. They are not going to be squashed away.
 - [ ] No "fix typo" / "address review" commits left in the history — fold
       them into the commit they belong to before requesting review.
 

.github/workflows/lint.yml

@@ -0,0 +1,38 @@
+# The org-wide lint gate. Drop this file in as
+# .github/workflows/lint.yml and change nothing else.
+#
+# The five checks it publishes are exactly the five contexts the
+# org ruleset requires:
+#
+#   lint / actionlint
+#   lint / JSON validity
+#   lint / prettier
+#   lint / markdownlint
+#   lint / yamllint
+#
+# Those strings come from the job being called `lint` and calling a
+# reusable workflow - a check publishes as "<caller job> / <called job>".
+# Do NOT convert this to a matrix: a matrix publishes
+# "lint (actionlint)" instead and will not satisfy the ruleset.
+#
+# Also copy .prettierrc, .prettierignore, .markdownlint.jsonc and
+# .yamllint.yaml from nyuchi/.github into your repo root.
+
+name: Lint
+
+on:
+  pull_request:
+  push:
+    branches: [main]
+  workflow_dispatch:
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: ${{ github.event_name == 'pull_request' }}
+
+permissions:
+  contents: read
+
+jobs:
+  lint:
+    uses: nyuchi/.github/.github/workflows/reusable-lint.yml@main

.markdownlint.jsonc

@@ -0,0 +1,39 @@
+// markdownlint-cli2 config for nyuchi/.github.
+//
+// Relaxed defaults that accommodate:
+//   - Long prose lines in docs (we format for readability, not width)
+//   - Inline HTML in the org profile (<div align="center">)
+//   - Files that start with an HTML comment or a <div> instead of an H1
+//   - Fenced code blocks without a language tag
+//
+// See https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md
+{
+  "default": true,
+
+  // Line length — we wrap for readability, not at a fixed column.
+  "MD013": false,
+
+  // Inline HTML — profile/README.md uses <div align="center"> for the
+  // landing-page layout and that's intentional.
+  "MD033": false,
+
+  // First line must be a top-level heading — profile/README.md opens
+  // with an HTML comment, which is correct.
+  "MD041": false,
+
+  // Fenced code blocks without a language — acceptable for output
+  // blocks and plain-text fences.
+  "MD040": false,
+
+  // Duplicate headings are fine as long as they aren't siblings
+  // (e.g. "## Summary" appears in multiple docs; that's expected).
+  "MD024": { "siblings_only": true },
+
+  // Unordered list indentation — 2 spaces, matching our house style.
+  "MD007": { "indent": 2 },
+
+  // Table-column-style — re-enabled now that Prettier is in CI and
+  // auto-formats tables. Prettier's table output should satisfy
+  // MD060's "aligned" style.
+  "MD060": true,
+}

.prettierignore

@@ -0,0 +1,30 @@
+# Prettier ignore for nyuchi/.github.
+
+# Standard ignores
+node_modules/
+.git/
+
+# Files with structural meaning that Prettier would harm
+LICENSE
+CODEOWNERS
+CODEOWNERS.example
+.github/CODEOWNERS
+
+# YAML is handled by yamllint and actionlint, not Prettier — they have
+# stronger guarantees about GitHub Actions semantics that Prettier does
+# not understand (e.g. the `on:` truthy quirk).
+*.yml
+*.yaml
+
+# Governance documents are authored by the Founder as legal / formal
+# documents. Prettier's markdown formatter reflows numbered paragraphs
+# ("2.2 The company pursues...") after a list as loose list-item
+# continuations, which corrupts the document's structure. Hand-format
+# these files.
+profile/governance/
+
+# Lockfiles, generated output
+*-lock.json
+*-lock.yaml
+package-lock.json
+pnpm-lock.yaml

.prettierrc

@@ -0,0 +1,16 @@
+{
+  "printWidth": 80,
+  "proseWrap": "preserve",
+  "tabWidth": 2,
+  "useTabs": false,
+  "endOfLine": "lf",
+  "trailingComma": "all",
+  "overrides": [
+    {
+      "files": ["*.md", "*.mdx"],
+      "options": {
+        "embeddedLanguageFormatting": "off"
+      }
+    }
+  ]
+}

.yamllint.yaml

@@ -0,0 +1,57 @@
+# yamllint config for nyuchi/.github.
+#
+# Relaxed defaults that accommodate:
+#   - GitHub Actions workflows (which use `on:` — a YAML 1.1 boolean)
+#   - Long lines in shell heredocs and comment blocks inside workflows
+#   - Files without `---` document-start markers
+#
+# See https://yamllint.readthedocs.io/en/stable/configuration.html
+
+extends: default
+
+ignore: |
+  node_modules/
+
+rules:
+  # 140-char limit. Workflow files have legitimately long shell URLs
+  # (the actionlint download script, action references) and issue-
+  # template `about:` strings render as a single line in the picker,
+  # so wrapping them would change user-visible behaviour. 140 is
+  # tight enough to flag truly excessive lines without forcing
+  # awkward breaks on URLs. Strict CI fails on any violation.
+  line-length:
+    max: 140
+    level: error
+    allow-non-breakable-words: true
+    allow-non-breakable-inline-mappings: true
+
+  # GitHub Actions uses `on:` as a key, which YAML 1.1 treats as a
+  # boolean. Disable the truthy check on keys to stop yamllint from
+  # rejecting every workflow.
+  truthy:
+    check-keys: false
+    level: error
+
+  # We don't prefix YAML files with `---`.
+  document-start: disable
+
+  # Be lenient about how many spaces follow `#` in comments.
+  comments:
+    min-spaces-from-content: 1
+
+  # Comments-indentation flags standalone comments that don't match the
+  # indent of surrounding content. Real-world configs use comments to
+  # delimit sections (long `# ----` separator banners) and to mark
+  # commented-out blocks at the level of the code they replace, neither
+  # of which fits the rule cleanly. Disabled.
+  comments-indentation: disable
+
+  # GitHub issue forms have deeply nested lists and mappings.
+  indentation:
+    spaces: 2
+    indent-sequences: consistent
+
+  # Stops a warning on the trailing-empty-line check for files that
+  # end cleanly with a single newline.
+  empty-lines:
+    max-end: 1

CODE_OF_CONDUCT.md

@@ -8,7 +8,6 @@
   that does not ship its own.
 -->
 
-
 # Contributor Covenant Code of Conduct
 
 ## Our Pledge
@@ -21,19 +20,19 @@ We pledge to act and interact in ways that contribute to an open, welcoming, div
 
 Examples of behavior that contributes to a positive environment for our community include:
 
-* Demonstrating empathy and kindness toward other people
-* Being respectful of differing opinions, viewpoints, and experiences
-* Giving and gracefully accepting constructive feedback
-* Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
-* Focusing on what is best not just for us as individuals, but for the overall community
+- Demonstrating empathy and kindness toward other people
+- Being respectful of differing opinions, viewpoints, and experiences
+- Giving and gracefully accepting constructive feedback
+- Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
+- Focusing on what is best not just for us as individuals, but for the overall community
 
 Examples of unacceptable behavior include:
 
-* The use of sexualized language or imagery, and sexual attention or advances of any kind
-* Trolling, insulting or derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or email address, without their explicit permission
-* Other conduct which could reasonably be considered inappropriate in a professional setting
+- The use of sexualized language or imagery, and sexual attention or advances of any kind
+- Trolling, insulting or derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or email address, without their explicit permission
+- Other conduct which could reasonably be considered inappropriate in a professional setting
 
 ## Enforcement Responsibilities
 
@@ -47,7 +46,7 @@ This Code of Conduct applies within all community spaces, and also applies when
 
 ## Enforcement
 
-Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at **conduct@nyuchi.com**. All complaints will be reviewed and investigated promptly and fairly.
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at **<conduct@nyuchi.com>**. All complaints will be reviewed and investigated promptly and fairly.
 
 All community leaders are obligated to respect the privacy and security of the reporter of any incident.
 
@@ -92,4 +91,3 @@ For answers to common questions about this code of conduct, see the FAQ at [http
 [Mozilla CoC]: https://github.com/mozilla/diversity
 [FAQ]: https://www.contributor-covenant.org/faq
 [translations]: https://www.contributor-covenant.org/translations
-

CONTRIBUTING.md

@@ -16,7 +16,7 @@ written down in `mzizi-dev/mzizi`'s `MIGRATION.md` §1.1:
 So: **your commits land on `main` exactly as you wrote them, and stay there.**
 That changes how you should work.
 
-- Write each commit as a coherent step, with a message that explains *why*.
+- Write each commit as a coherent step, with a message that explains _why_.
   Nobody is going to squash your "wip" and "fix typo" commits away for you.
 - Clean the branch up before requesting review — `git rebase -i` on your own
   branch, not on `main`.