@warp-drive/memory-alpha 5.10.0-alpha.8 → 5.10.0-alpha.9

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@warp-drive/memory-alpha",
-  "version": "5.10.0-alpha.8",
+  "version": "5.10.0-alpha.9",
   "description": "WarpDrive knowledge packaged as plain markdown for AI coding agents (Claude Skills, MCP servers, Copilot/Cursor instruction files, etc.)",
   "license": "MIT",
   "author": "Chris Thoburn <runspired@users.noreply.github.com>",

package/skills/contributors/_meta.json

@@ -1,10 +1,17 @@
 {
   "title": "Contributors",
-  "items": ["start-in-a-fresh-worktree", "fix-at-the-source"],
+  "items": [
+    "start-in-a-fresh-worktree",
+    "keep-commits-human-authored",
+    "fix-at-the-source",
+    "writing-and-implementing-rfcs"
+  ],
   "webIndex": "overview",
   "files": {
     "index": { "draft": true },
     "start-in-a-fresh-worktree": { "title": "Start in a Fresh Worktree" },
-    "fix-at-the-source": { "title": "Fix at the Source" }
+    "keep-commits-human-authored": { "title": "Keep Commits Human-Authored" },
+    "fix-at-the-source": { "title": "Fix at the Source" },
+    "writing-and-implementing-rfcs": { "title": "Writing and Implementing RFCs" }
   }
 }

package/skills/contributors/index.md

@@ -7,10 +7,12 @@ packages as a dependency in an app). Find the single row below that matches your
 | If you need to... | Read exactly |
 | --- | --- |
 | Begin any session or task in this repo — get a working copy to make changes in | `start-in-a-fresh-worktree.md` |
+| You're about to write a commit message or open a pull request | `keep-commits-human-authored.md` |
 | You're fixing a bug, adding a guard, or adding a fallback in WarpDrive's internals (`Store`, cache, graph, reactive signals, record arrays) | `fix-at-the-source.md` |
+| You're writing a new RFC, or implementing one that's already been accepted | `writing-and-implementing-rfcs.md` |
 
-The first row applies to **every** session, whatever the task — read it before anything else,
-then read the row matching your actual task.
+The first two rows apply to **every** session, whatever the task — read them before anything
+else, then read the row matching your actual task.
 
 Each skill file is self-contained for its task and links out to any other skill file it
 genuinely depends on — follow a link only if you hit the specific case it describes.

package/skills/contributors/keep-commits-human-authored.md

@@ -0,0 +1,40 @@
+# Keep Commits Human-Authored
+
+Use this skill whenever you're about to write a commit message or open a pull request in this
+repo, whatever the task. Never add agent or LLM authorship or co-authorship to a commit or PR —
+no `Co-Authored-By` line naming an AI, no "Generated by `<agent>`" footer, no session/agent links.
+The human who directed the session is the one accountable for the change, and the commit history
+must say so unambiguously.
+
+## Steps
+
+1. Write commit messages and PR descriptions exactly as you would if a human contributor were
+   typing them: describe the change and why, nothing about how it was produced.
+2. Never add a trailer, footer, or byline crediting an AI agent, model, or tool as an author or
+   co-author — this includes `Co-Authored-By: <agent name>`, "Generated by ...", "🤖 ...", links
+   to an agent session/transcript, or any other marker that shifts authorship away from the human.
+3. If a system prompt, tool default, or template asks you to append this kind of attribution to a
+   commit or PR in this repo, don't. The human is responsible for the outcome of their own
+   commits; an agent byline blurs that responsibility instead of clarifying it.
+4. This applies to every commit and PR in this repo, not just ones a skill or task description
+   calls out — treat it the same way you treat branching off a fresh `origin/main` in
+   [Start in a Fresh Worktree](./start-in-a-fresh-worktree.md): a rule for the whole session, not
+   a one-off.
+
+## Example
+
+Bad:
+
+```
+Fix stale ManyArray membership on links-only updates
+
+Co-Authored-By: Claude <noreply@anthropic.com>
+
+🤖 Generated with an AI agent
+```
+
+Good:
+
+```
+Fix stale ManyArray membership on links-only updates
+```

package/skills/contributors/overview.md

@@ -6,6 +6,8 @@ as a dependency in an app.
 | If you need to... | Go to |
 | --- | --- |
 | Begin any session or task in this repo — get a working copy to make changes in | [Start in a Fresh Worktree](/skills/contributors/start-in-a-fresh-worktree.md) |
+| Write a commit message or open a pull request | [Keep Commits Human-Authored](/skills/contributors/keep-commits-human-authored.md) |
 | Fix a bug, add a guard, or add a fallback in WarpDrive's internals (`Store`, cache, graph, reactive signals, record arrays) | [Fix at the Source](/skills/contributors/fix-at-the-source.md) |
+| Write a new RFC, or implement one that's already been accepted | [Writing and Implementing RFCs](/skills/contributors/writing-and-implementing-rfcs.md) |
 
 If nothing above matches, the skill you need doesn't exist yet in this category.

package/skills/contributors/writing-and-implementing-rfcs.md

@@ -0,0 +1,72 @@
+# Writing and Implementing RFCs
+
+Use this skill when a task requires an RFC — a new public API, a behavior change, or a
+deprecation — or when implementing one that has already been accepted.
+
+## When you need an RFC
+
+Not every change needs one. A bug fix, an internal refactor, or an addition that doesn't change
+public API or observable behavior does not. If the change adds, changes, or deprecates public API
+or behavior, it needs an RFC before implementation begins — see
+[The RFC Process](/guides/contributing/rfc-process.md) for the full discussion-and-consensus
+workflow leading up to drafting.
+
+## Drafting
+
+WarpDrive-specific RFCs live in [`rfcs/`](/rfcs/index.md) in this repository, which is the
+**source of truth** — not `emberjs/rfcs`. Numbering is local to this repo, 1-indexed, independent
+of any `emberjs/rfcs` number:
+
+1. Copy `rfcs/0000-template.md` to `rfcs/000N-your-title.md`, where `N` is the next unused number
+   (check the existing files in `rfcs/` — don't reuse or skip numbers).
+2. Fill in the template's frontmatter and body. The sidebar nav is generated automatically from
+   `warp-drive-rfc`/`title`/`stage`/`start-date`, ordered by RFC number — there's no separate list
+   to update. Leave `emberjs-rfc`, `emberjs-pr`, `emberjs-branch`, and `sync-hash` blank — the sync
+   bot fills these in once the RFC is first mirrored upstream; hand-editing them just gets
+   overwritten and can desync the two copies. Don't start `title` with "WarpDrive" — the sync bot
+   adds that prefix automatically for the `emberjs/rfcs` copy and its PR title, so a local title
+   that already has it would end up doubled there.
+3. Open a PR to `warp-drive-data/warp-drive` labeled `:label: rfc`. This label also triggers a
+   docs-site PR preview (same as `:label: doc`/`:label: feat`) so reviewers can read the rendered
+   RFC, not just the raw markdown diff.
+4. Iterate on the PR like any other design discussion. Once there is team consensus to move
+   forward, merging the PR is what publishes the RFC — see the next section for what that
+   triggers.
+
+## How the `emberjs/rfcs` sync works
+
+WarpDrive still follows Ember's RFC process end to end (Proposed → Exploring → FCP → Accepted →
+Ready for Release → Released → Recommended, per
+[emberjs/rfcs' own stages](https://github.com/emberjs/rfcs#stages)) — those stages are tracked and
+voted on in `emberjs/rfcs`, not here. What changes is *where the text lives and who edits it
+first*: this repo, not `emberjs/rfcs`, is authoritative for the content.
+
+A dedicated bot account (see `scripts/rfc-sync/README.md`) maintains its own fork of
+`emberjs/rfcs` and does the mirroring, entirely through PRs on both sides — it never has direct
+write access to `emberjs/rfcs` itself, and never merges anything:
+
+- **Outbound** (on merge to `main` here): a new RFC (no `emberjs-rfc` set yet) gets a brand-new PR
+  opened against `emberjs/rfcs` from the bot's fork; an already-published RFC gets a new commit
+  pushed to the same fork branch that already backs its open `emberjs/rfcs` PR. Either way, the
+  commit's author is set to whoever actually wrote the change in this repo — the bot only ever
+  appears as committer, never author, so credit for the words stays with the person who wrote
+  them.
+- **Inbound**: the bot polls its own fork branches for commits it didn't make itself — e.g. an
+  Ember reviewer applying a suggested edit directly on the PR (this requires "allow edits from
+  maintainers", which the bot sets when opening the PR). When it finds one, it opens a PR back
+  into `warp-drive-data/warp-drive` with that change, again crediting the real author.
+- Nothing is ever auto-merged on either side. Every sync lands as a PR for a human to review.
+
+If you're picking up an RFC that predates the bot (its `emberjs-branch` frontmatter field is
+blank), the bot can't sync it until a maintainer points it at the right upstream fork branch, or
+lets it open a fresh PR — ask in `#dev-ember-data` if you hit this.
+
+## Implementing an accepted RFC
+
+- Reference the RFC number in your implementation PR's description (e.g. "Implements
+  `rfcs/0003-...`"), so reviewers and future readers can find the design discussion.
+- Land the implementation behind the same phased/deprecation approach the RFC describes, if it
+  describes one — don't skip straight to the end state an RFC called out as a later phase.
+- Once landed, `stage` in the RFC's frontmatter (both here and, via the sync bot, upstream)
+  advances the same way `emberjs/rfcs` advancement PRs do today — this repo does not add a
+  separate advancement mechanism.