- canon/standards/contribution-convention_v0.1.md: master spec for BR/FR/EP/UPR artifact types, directory layout, frontmatter schema, ID schemes (EP-DOMAIN-NNN for extension points), status lifecycle, and relationship to State Hub - canon/standards/contrib-templates/: four template files (br, fr, ep, upr) - contrib/upstream-prs/2026-02-26--observablehq--framework--toc-sidebar-inject.md: first real UPR artifact — proposes injectTocTop() to Observable Framework Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
1.1 KiB
1.1 KiB
id, type, ep_id, target_org, target_repo, title, status, domain, related_workstream, state_hub_contribution_id, created, updated, location, upstream_issue_url
| 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 | custodian | 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.