the-custodian/canon/standards/contrib-templates/ep-template.md
codex 450b4b80b0
Some checks are pending
CI Smoke / host-smoke (push) Waiting to run
CI Smoke / container-smoke (push) Waiting to run
Python Tests / pytest (push) Successful in 21s
canon: distinguish sector domains from project identity
2026-08-23 01:47:39 +02:00

1.2 KiB

id type ep_id target_org target_repo title status domain related_workstream state_hub_contribution_id created updated location upstream_issue_url
EP-DOMAIN-NNN ep EP-DOMAIN-NNN <github-org-or-owner> <repository-name> Short description of the extension point draft infotech null null YYYY-MM-DD YYYY-MM-DD src/file.ts:42 null

Extension Point Proposal: EP-DOMAIN-NNN

Summary

One-paragraph description of the extension point: where in the upstream codebase it would live, what it would enable, and who would benefit.

Location

File: <path/in/upstream/repo> Line: approximate location where the hook/callback would be inserted

Proposed Interface

// or Python, Rust, etc. — match the upstream project's language
interface ExtensionPoint {
  // …
}

Rationale

Why this extension point is valuable. What use cases does it unlock? Why should upstream accept it rather than keeping it local?

Implementation Sketch

Brief notes on how upstream might implement this, if relevant.

Notes

References to related upstream issues, PRs, or discussions.