Extension registry

The non-normative registry of known extension namespaces, grouped by status. Inclusion is advisory — neither a requirement to use a namespace nor an endorsement. Any reverse-DNS actor MAY claim a namespace; consumers preserve unknown namespaces on round-trip.

• org.projectfile.build — The BUILD-ARGUMENT surface a project’s container build depends on, declared ONCE and lowered to BOTH the local make plane (m6e) and a forge CI plane (the pf-ci).

• org.projectfile.image — The image a project publishes, declared as PARTS and TEMPLATES: the repository path, the tags each kind of build publishes (heads), and how a build variant enters a tag (variant).
• org.projectfile.spec — Self-description extension used by the specification repository to declare which spec versions live alongside the file..
• org.spiderlint — Settings for spiderlint, a site-wide linter for SEO tags, security headers, TLS and links: shared crawl and rule settings, plus one entry per site under sites, each audited in its own store..

• com.github.dependabot — Dependabot-specific extras: open-prs-limit, target-branch, and per-ecosystem ignore rules.
• com.npmjs.registry — npm registry URL, scope routing, publish access level, dist-tag, and provenance attestation.
• org.ignorelint — Lint policy for ignorelint, a linter for .gitignore, .dockerignore and other *ignore files: failure threshold, output format, autofix, discovery, disabled rules and per-rule severity overrides..
• org.opentelemetry.resource — Declares static OpenTelemetry resource attributes (service.name, service.namespace).
• org.packagist.composer — Composer project-metadata passthrough for composer.json sync: carries the composer-only fields that have no native projectfile slot so a project regenerated from projectfile alone still round-trips composer.json — type, minimum-stability, prefer-stable, and abandoned.
• org.packagist.registry — Composer repository list, minimum-stability, and prefer-stable flags.
• org.projectfile.acknowledgements — The README’s post-licence credits, in four lists: contributors (the people who built the project), thanks (people or organisations owed a mention), sponsors (who funds the work), and credits (the projects and technologies this one builds on).
• org.projectfile.ai — A project’s stance on AI and LLM use, over three independent directions.
• org.projectfile.architecture — Platform targeting for a project: org.projectfile.architecture (CPU arch set) and its companion org.projectfile.operating-system (OS set).
• org.projectfile.artifacts — A map of NAMED artifacts a project PRODUCES — the container images it publishes, the packages it ships to a registry, the executables it installs, the services it exposes, the sites it deploys.
• org.projectfile.ci — Vendor-agnostic CI intent expressed as a DAG of free-named state NODES (e.g.
• org.projectfile.citation — Citation metadata supplement for CITATION.cff and codemeta.json generation.
• org.projectfile.cli — Bookkeeping surface for the projectfile CLI: derived[] tracks every field path the CLI has populated via the derivation layer (forge URLs, registry URLs) so subsequent runs can re-derive without trampling user edits, and derive.* toggles disable individual inference passes.
• org.projectfile.code-of-conduct — Code of Conduct declaration: which covenant, scope, and typed URL sequence for enforcement and full-text links.
• org.projectfile.codeowners — Ordered entries mapping glob patterns to code owners for CODEOWNERS generation.
• org.projectfile.contributing — Contribution process parameters for CONTRIBUTING.md generation: contributor-agreement type, review requirements, workflow model (github-flow, git-flow, gitlab-flow, trunk-based, centralized), commit and branch conventions, and typed URL sequence for CLA, coding-standards, review-guide, and first-contribution links.
• org.projectfile.conventions — Cross-cutting workflow conventions read by multiple generators: commit-style, workflow model, style-guide-url (top-level or per-technology-tag), the tool-agnostic code-style block (line-length), and the fragment-assembly defaults (documents shells + flat parents list) consumed by pf-bridge-fragments.
• org.projectfile.dei — DEI.md project statement (CHAOSS / badging DEI Project Badge).
• org.projectfile.dependency-updates — Shared source of truth for automated dependency update configuration: global schedule, automerge default, reviewer assignments, labels, and per-ecosystem overrides.
• org.projectfile.editors — Editor/IDE ignore rules for .gitignore generation — distinct from stack tags (editors describe developer tooling, not project technology).
• org.projectfile.env — Declares the environment variable contract for the project: required and optional vars with descriptions, examples, and allowed-value lists.
• org.projectfile.events — Vendor-agnostic OUTBOUND lifecycle-event surface — the dual of org.projectfile.ci’s inbound triggers.
• org.projectfile.forge — Portable, tool-agnostic forge-publishing metadata: any conforming tool MAY read it to decide which description / homepage / topics and which branch and tag protection get synced from projectfile to GitHub / GitLab / Forgejo / Gitea repositories.
• org.projectfile.fragments — Explicit override for pf-bridge-fragments document assembly.
• org.projectfile.funding — Unified funding configuration: GitHub Sponsors / Patreon / Ko-fi / etc.
• org.projectfile.health — Shared shape for declaring application health-check surfaces (liveness, readiness, startup probes).
• org.projectfile.i18n — The languages a project publishes its generated documents in, as BCP 47 tags, plus the project’s primary language (default-language, defaults to “en”).
• org.projectfile.ignores — Declares which ignore files to generate and the patterns each one carries.
• org.projectfile.readme — README.md generation control: ordered list of named template blocks that compose the output.
• org.projectfile.release — Release conventions: tag format and prefix, changelog style, commit-message convention, and branch-to-channel mappings.
• org.projectfile.security — Security policy parameters for SECURITY.md generation: reporting channel, response SLAs, disclosure window, severity model, CVE handling, bug bounty, supported-version table, out-of-scope list, and announcement channels.
• org.projectfile.status — Advisory project lifecycle status (a single scalar).
• org.projectfile.support — Support policy for SUPPORT.md generation: community response-time SLA, typed URL sequence for paid-support and status-page links, and end-of-life date table per version series.
• org.projectfile.tests — Tool-agnostic minimum percentages a project’s test suite must reach: statement coverage and mutation efficacy.
• org.projectfile.vulnerabilities — Tool-agnostic list of suppressed vulnerability IDs (CVE/GHSA) that fans the same set out to every scanner ignore file the project runs: .trivyignore (trivy), .grype.yaml (grype), osv-scanner.toml (osv).
• org.python.index — Python package index URLs for install (pip, uv) and publish (twine, uv publish).
• org.python.pep621 — PEP 621 project-metadata passthrough for pyproject.toml sync: carries the Python-only fields that have no native projectfile slot so a project regenerated from projectfile alone still round-trips pyproject.toml — readme, scripts, gui-scripts, entry-points, optional-dependencies, dynamic, and classifiers.