Use get_test_spec and read renamed finalize keys (0.2.10)

CHANGELOG.md

@@ -2,11 +2,26 @@
 
 All notable changes to Doable Agent Plugins are documented here.
 
+## [0.2.10] - 2026-09-30
+
+### Changed
+
+- Say "test spec" instead of "TRD" in the skills, helper output, and documentation,
+  following Doable's rename of the Test Requirement Document (TRD) to test spec.
+- Read the current test spec with the Doable MCP tool `get_test_spec`. This requires
+  the updated Doable MCP server, which keeps `get_trd` as a deprecated alias for
+  earlier plugin versions.
+- `record-finalize` reads `test_spec_id` / `test_spec_session_id` and falls back to
+  the pre-rename `trd_id` / `trd_session_id`, so it works with a Doable MCP server
+  from either side of the rename. New finalize receipts store `testSpecId` /
+  `testSpecSessionId`.
+- Add the `test-spec` keyword to every host manifest; `trd` stays for discoverability.
+
 ## [0.2.9] - 2026-09-26
 
 ### Added
 
-- Report investigation stages and the current question to the TRD editor, with
+- Report investigation stages and the current question to the test spec editor, with
   updates during long active work at the next tool boundary (about 60 seconds).
 - Fall back to phase-only reporting on older MCP/backend deployments; never
   report artificial activity during idle connection polling.
@@ -17,9 +32,9 @@ All notable changes to Doable Agent Plugins are documented here.
 
 ### Fixed
 
-- Accept a server-bound pre-create successor when a TRD needs more context to
+- Accept a server-bound pre-create successor when a test spec needs more context to
   finish creation. Keep checking the original connection code and local workspace.
-- Requires the matching TRD connection resolver fix; older servers retain their
+- Requires the matching test spec connection resolver fix; older servers retain their
   existing behavior. Cross-repository contract: `getdoable/trd`
   `docs/change-sets/pre-create-code-context-toggle.yaml`.
 
@@ -31,7 +46,7 @@ All notable changes to Doable Agent Plugins are documented here.
   merged after 0.2.6: persistent follow-up watching, journey declarations, and
   result observation. A reused version can leave an installed plugin cached.
 - Follow the server's next-action decision when a pre-create Round hands over
-  to TRD follow-ups, and omit journey declarations when the Round did not
+  to test spec follow-ups, and omit journey declarations when the Round did not
   request them, preserving compatibility with older backends.
 - Align the local helper's client version with the plugin release.
 
@@ -54,7 +69,7 @@ All notable changes to Doable Agent Plugins are documented here.
 - Bundle the official remote Doable MCP connection for Codex, Claude Code, and Cursor.
 - Ask for `DOABLE_API_KEY` as a required Cursor installation variable so a
   first-time user authenticates while installing the plugin.
-- Define the cold-start acceptance path from a TRD Editor copy prompt through
+- Define the cold-start acceptance path from a Test Spec Editor copy prompt through
   plugin approval, authentication, exact-Round preflight, and automatic resume.
 
 ## [0.2.4] - 2026-09-07
@@ -73,10 +88,10 @@ All notable changes to Doable Agent Plugins are documented here.
 
 ### Changed
 
-- Keep one post-create context connection open across sequential TRD follow-up
+- Keep one post-create context connection open across sequential test spec follow-up
   Rounds. The original copied DQ code resolves to the newest published Round
   until the user stops the coding-agent task.
-- Fetch the current TRD for each newly resolved follow-up Round while keeping
+- Fetch the current test spec for each newly resolved follow-up Round while keeping
   code, tests, and runtime evidence descriptive rather than treating it as
   authoritative product intent.
 
@@ -89,7 +104,7 @@ All notable changes to Doable Agent Plugins are documented here.
 
 ### Changed
 
-- Watch one published Round until the editor continues TRD generation. `record-round`
+- Watch one published Round until the editor continues test spec generation. `record-round`
   prints `Next action: answer|wait|stop`, keeps same-round answers as established
   context, and does not treat `ready_to_create` as finished.
 - `record-submission` keeps one receipt per payload digest so a later batch on the
@@ -110,8 +125,8 @@ All notable changes to Doable Agent Plugins are documented here.
 ### Added
 
 - Doable Code Context for Codex, Claude Code, and Cursor.
-- MCP-backed pre-TRD context rounds with grounded, privacy-safe findings.
-- Coding-agent-first feature testing through the existing Doable suite, TRD, and managed-case workflow.
+- MCP-backed pre-test-spec context rounds with grounded, privacy-safe findings.
+- Coding-agent-first feature testing through the existing Doable suite, test spec, and managed-case workflow.
 - Demand-driven mono-repo and multi-repo workspace mapping with local-only provenance.
 
 ### Changed

README.md

@@ -7,21 +7,21 @@ Official agent plugins for [Doable](https://getdoable.ai), supporting Codex, Cla
 
 | Plugin | Version | Purpose | Network |
 | --- | --- | --- | --- |
-| `doable-code-context` | `0.2.9` | Resolve context requests or start a managed feature-testing workflow | Doable MCP |
+| `doable-code-context` | `0.2.10` | Resolve context requests or start a managed feature-testing workflow | Doable MCP |
 
 ## Workflow
 
-Use **Doable Code Context** for the connected pre-TRD workflow:
+Use **Doable Code Context** for the connected pre-test-spec workflow:
 
-1. The user submits a TRD request in Doable.
+1. The user submits a test spec request in Doable.
 2. Doable shows the original feature request as the required base investigation,
-   adds any focused TRD Assistant questions, and lets the user review or add
+   adds any focused Test Spec Assistant questions, and lets the user review or add
    questions before publishing one Round with a short copy prompt such as:
 
    ```text
    Use the `doable-answer-questions` skill to resolve Doable context request
    DQ-7F3K for organization HireEZ (hireez). Keep watching until the editor
-   continues TRD generation. If the plugin is missing, install it from
+   continues test spec generation. If the plugin is missing, install it from
    https://github.com/getdoable/doable-agent-plugins#install.
    ```
 
@@ -32,11 +32,11 @@ Use **Doable Code Context** for the connected pre-TRD workflow:
    branch/commit, then pulls that Round and answers from the private
    repositories. If a word in the brief could mean more than one thing in the
    code, it asks the user locally. After the first paste, new questions from the
-   TRD-editor arrive on the same Round automatically — do not copy the prompt
+   test spec editor arrive on the same Round automatically — do not copy the prompt
    again.
-4. The coding agent keeps watching until the TRD-editor continues TRD generation
+4. The coding agent keeps watching until the test spec editor continues test spec generation
    or the Round is cancelled. `ready_to_create` is not finished. Doable then
-   continues the existing TRD create loop.
+   continues the existing test spec create loop.
 
 The Round does not transfer a Git branch, PR, worktree, commit, dirty state, or
 code graph. Before answering, the coding agent verifies that any named target
@@ -129,17 +129,17 @@ Cursor and Claude Code load `plugins/doable-code-context/.mcp.json`; the Codex m
 
 ## Use Doable Code Context
 
-Normally, paste the short prompt copied from the Doable TRD-editor once:
+Normally, paste the short prompt copied from the Doable Test Spec Editor once:
 
 ```text
 Use the `doable-answer-questions` skill to resolve Doable context request
 DQ-7F3K for organization HireEZ (hireez). Keep watching until the editor
-continues TRD generation. If the plugin is missing, install it from
+continues test spec generation. If the plugin is missing, install it from
 https://github.com/getdoable/doable-agent-plugins#install.
 ```
 
-The coding agent watches that same Round until Continue generating TRD. Later
-questions from the TRD-editor do not need a new prompt.
+The coding agent watches that same Round until the editor continues test spec
+generation. Later questions from the test spec editor do not need a new prompt.
 
 Setup is recovered inside the same conversation if needed. The user may also request it directly:
 
@@ -155,7 +155,7 @@ Use Doable to test the feature I just implemented.
 
 The agent reuses or creates the appropriate suite, opens one coding-agent-origin
 Round only when context or requirements changed, resolves that Round from the
-private workspace, and then continues through the existing TRD and managed-case
+private workspace, and then continues through the existing test spec and managed-case
 workflow.
 
 The connected plugin writes private state under:

TESTING.md

@@ -6,7 +6,7 @@ For every scenario, confirm that the agent inspects only evidence needed for the
 
 ## Connected workflow
 
-1. **Cold install from the TRD Editor** — Start TRD creation, publish a fresh Code Context Round, and copy its prompt. Paste it into a Codex, Claude Code, or Cursor agent that has never installed Doable and has no Doable MCP entry. The agent detects the missing Skill from its loaded skill catalog, preserves the exact DQ and organization while installation completes, and loads the plugin-declared `doable` MCP connection. Cursor must request `DOABLE_API_KEY` during plugin installation; Codex and Claude Code must resolve it from their launch environment. The original DQ continues without another paste. No repository scan may start before the authenticated preflight succeeds.
+1. **Cold install from the Test Spec Editor** — Start test spec creation, publish a fresh Code Context Round, and copy its prompt. Paste it into a Codex, Claude Code, or Cursor agent that has never installed Doable and has no Doable MCP entry. The agent detects the missing Skill from its loaded skill catalog, preserves the exact DQ and organization while installation completes, and loads the plugin-declared `doable` MCP connection. Cursor must request `DOABLE_API_KEY` during plugin installation; Codex and Claude Code must resolve it from their launch environment. The original DQ continues without another paste. No repository scan may start before the authenticated preflight succeeds.
 2. **Plugin reinstall** — Install a newer plugin version over a prior release in each supported host. Expect the host to replace the packaged Skill and MCP declaration and expose the new version only after installation completes. Cursor also requests a missing required variable. A source checkout or symlink change alone is not an installed-plugin update.
 3. **Copied-Round authentication preflight** — Paste a Round prompt with no working `doable` connection. Expect `get_code_context_connection` with the exact `round_code` before the agent uses `.doable` state or scans code; it may read only an optional `workspace.clientRef` for that preflight. After the user supplies the target organization's key once, expect the agent to configure only the host's user-scoped MCP connection. In Cursor, make the old live transport return `401` immediately after replacement; expect the agent to wait for the asynchronous MCP refresh and retry before rejecting the new key. In Claude Code, the only remaining user action is `/mcp` → reconnect `doable`; the agent then retries and resumes the original Round without a restart, new session, or second prompt.
 4. **Coding-agent-origin authentication preflight** — Start a feature-testing request without a copied Round. Expect `get_code_context_connection` before local workspace setup or remote suite search. Recover the connection once and resume the original feature request automatically.
@@ -15,7 +15,7 @@ For every scenario, confirm that the agent inspects only evidence needed for the
 7. **Mono-repo and multi-repo** — Confirm every independent Git root receives a stable opaque `repoRef`, while a common parent directory does not. Move one repository and explicitly reuse its `repoRef`; expect identity to survive the path change.
 8. **Profile privacy** — Use repository names, paths, branches, commits, and an internal service name that differ from the safe product role. Capture the PUT body and confirm none appears remotely. The local state must retain them.
 9. **Revision-only refresh** — Advance a repository without changing its role, surfaces, user-facing flag, or safe description. Expect a sync without new user approval. Change a material field and expect approval to be required.
-10. **Watch one Round** — Pull a valid `DQ-...` code. Confirm `Next action: answer` while `open_for_agent` has open questions, and `wait` for `ready_to_create` / `needs_attention`. A pre-create Round that reaches `creating` or `consumed` also answers `wait`: it hands its code to the follow-up Rounds of the TRD it just created, so the watch continues on the same DQ. Expect `stop` only for `cancelled`, or for a pre-create Round bound to no session. A later pull may add `established_context` plus new open questions; the candidate must cover only the new open IDs. Do not treat `ready_to_create` as finished.
+10. **Watch one Round** — Pull a valid `DQ-...` code. Confirm `Next action: answer` while `open_for_agent` has open questions, and `wait` for `ready_to_create` / `needs_attention`. A pre-create Round that reaches `creating` or `consumed` also answers `wait`: it hands its code to the follow-up Rounds of the test spec it just created, so the watch continues on the same DQ. Expect `stop` only for `cancelled`, or for a pre-create Round bound to no session. A later pull may add `established_context` plus new open questions; the candidate must cover only the new open IDs. Do not treat `ready_to_create` as finished.
 11. **Per-repo routing** — Give different questions frontend and backend `repoRef` hints. Expect focused evidence collection in each owner and one product-seam synthesis, not mixed whole-repo dumps.
 12. **Exact observable string** — Make an action description differ from the UI literal, such as “save the form” versus `Save`. Expect the finding and anchor to use the verified literal only.
 13. **Existence versus absence** — Ask whether a validation exists. Positive evidence may establish existence. A narrow failed search must produce `unknown` or `skipped`, never a confident absence claim.
@@ -26,7 +26,7 @@ For every scenario, confirm that the agent inspects only evidence needed for the
 17. **Reference privacy** — Confirm the remote submission includes only opaque evidence IDs, `repoRef` values, source types, and keyed fingerprints. Exact files, symbols, lines, revisions, and source content remain local.
 18. **Idempotent retry** — Submit the same candidate twice. Expect one network submission and a local same-digest receipt. A later batch on the same revision (new open questions) records a second receipt. Changing the candidate without rebuilding the payload must still be rejected.
 19. **Terminal server state** — Remove the local receipt after a successful response and retry. Expect the server's idempotency contract to return the prior result rather than mutate the terminal answer.
-20. **No TRD side effect** — Completing an answer batch must keep watching until `Next action: stop`. The plugin must not create a TRD, generate cases, or run tests. `ready_to_create` is not completion.
+20. **No test spec side effect** — Completing an answer batch must keep watching until `Next action: stop`. The plugin must not create a test spec, generate cases, or run tests. `ready_to_create` is not completion.
 21. **Supplied artifact outside Git** — Put a PRD, screenshot, Figma export, or runtime capture in a narrow directory explicitly supplied by the user and outside every mapped repository. Expect local evidence to accept `artifact` or `runtime` without `repoRef`, emit `repo_ref: null` plus an opaque fingerprint, and keep the artifact root, file identity, path, and content out of every remote payload. Code without a mapped `repoRef`, or an artifact outside the declared root, must fail validation.
 22. **Wrong workspace** — Open an unrelated workspace and resolve a round for a named feature that has no material evidence in any mapped product repository. Expect the agent to stop with a concise wrong-workspace warning. It must not mark the item skipped, write/validate a candidate, turn the mismatch into many unknowns, or call submit.
 23. **Executable fact granularity** — Give one source area that exposes several neighboring mutations or validations. Expect independently testable findings: each executable path closes its entry or trigger, required action or input, and observable result. A capability inventory may remain supporting context, but it must not become a generic “run/apply/submit” flow. Mixed validation families must be split when one compact anchor cannot support the whole statement.

package.json

@@ -1,6 +1,6 @@
 {
   "name": "doable-agent-plugins",
-  "version": "0.2.9",
+  "version": "0.2.10",
   "private": true,
   "description": "Official installable agent plugins for Doable.",
   "license": "MIT",

plugins/doable-code-context/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "doable-code-context",
-  "version": "0.2.9",
+  "version": "0.2.10",
   "description": "Connect private code to Doable through MCP, resolve grounded context requests, and start managed feature-testing workflows.",
   "author": {
     "name": "Doable AI",
@@ -12,6 +12,7 @@
   "keywords": [
     "doable",
     "testing",
+    "test-spec",
     "trd",
     "code-context"
   ],

plugins/doable-code-context/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "doable-code-context",
-  "version": "0.2.9",
+  "version": "0.2.10",
   "description": "Connect private code to Doable through MCP, resolve grounded context requests, and start managed feature-testing workflows.",
   "author": {
     "name": "Doable AI",
@@ -12,6 +12,7 @@
   "license": "MIT",
   "keywords": [
     "doable",
+    "test-spec",
     "trd",
     "testing",
     "code-context",

plugins/doable-code-context/.cursor-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "doable-code-context",
   "displayName": "Doable Code Context",
-  "version": "0.2.9",
+  "version": "0.2.10",
   "description": "Connect private code to Doable through MCP, resolve grounded context requests, and start managed feature-testing workflows.",
   "author": {
     "name": "Doable AI"
@@ -11,6 +11,7 @@
   "keywords": [
     "doable",
     "testing",
+    "test-spec",
     "trd",
     "code-context",
     "agent-skills"