feat: release Doable TRD Context 0.1.5

README.md

@@ -1,92 +1,162 @@
 # Doable Agent Plugins
 
-Official beta agent plugins for [Doable](https://getdoable.ai).
+Official beta plugins for [Doable](https://getdoable.ai). The current release is **Doable TRD Context 0.1.5**.
 
-The repository is currently private. GitHub access to `getdoable/doable-agent-plugins` is required for installation during the private beta; the package can be tested normally before the repository is made public.
+Doable TRD Context lets a customer's coding agent inspect one clearly identified feature in a private codebase and prepare the product and testing context needed to create a Doable TRD. Doable never receives repository access. The user uploads one generated file: `doable-context.md`.
 
-The first plugin, **Doable TRD Context**, helps a coding agent inspect one clearly identified feature in a private mono-repo or multi-repo and create one privacy-safe, evidence-grounded `doable-context.md` file. The user then uploads that single file to Doable to create a TRD.
+The repository is private during the beta. Installation requires GitHub access to `getdoable/doable-agent-plugins`.
 
-This beta is deliberately context-only: it does not include MCP, authenticate to Doable, create a TRD, generate test cases, or run tests.
+## Current product boundary
+
+The plugin:
+
+- works with Codex, Claude Code, and Cursor;
+- understands mono-repos, multi-repo workspaces, selected PRs or diffs, tickets, PRDs, screenshots, and other supplied design artifacts;
+- grounds feature scope, actors, flows, states, rules, observable outcomes, fixture requirements, environment constraints, exclusions, and bounded unknowns;
+- keeps repository identities, source locations, revisions, dirty state, and evidence provenance local;
+- creates one privacy-safe context file for manual upload to Doable.
+
+This context-only beta does **not** configure MCP, authenticate to Doable, create or update a TRD, generate test cases, or run tests.
 
 ## Requirements
 
-- Codex, Claude Code, or Cursor with Agent Skills/plugin support;
+- Codex, Claude Code, or Cursor with Agent Skills or plugin support;
 - Node.js 20 or newer for deterministic validation and rendering;
-- Git available locally for repository-bound provenance checks.
+- Git for repository-bound evidence and refresh checks.
+
+## Install
 
-## Install in Codex
+### Codex
 
 ```bash
 codex plugin marketplace add getdoable/doable-agent-plugins --ref main
 codex plugin add doable-trd-context@getdoable
 ```
 
-Start a new task after installation. Example:
+Start a new task after installation.
 
-```text
-Test the authentication feature. Prepare the context I need to create a Doable TRD.
-```
-
-## Install in Claude Code
+### Claude Code
 
 ```bash
 claude plugin marketplace add getdoable/doable-agent-plugins
 claude plugin install doable-trd-context@doable --scope user
 ```
 
-Start a new session or run `/reload-plugins`. The explicit command is `/doable-trd-context:doable-trd-intake`; natural-language requests work too.
+Start a new session after installation or update. Natural-language requests activate the Skill; the explicit invocation is `/doable-trd-context:doable-trd-intake`.
 
-## Install in Cursor
+### Cursor
 
 In a new Cursor Agent chat, try:
 
 ```text
 /add-plugin doable-trd-context@https://github.com/getdoable/doable-agent-plugins
 ```
 
-For local beta development, clone this repository and symlink it into Cursor, then fully restart Cursor:
+For local beta development, clone the repository, link the plugin directory, and fully restart Cursor:
 
 ```bash
 git clone https://github.com/getdoable/doable-agent-plugins.git
 mkdir -p ~/.cursor/plugins/local
 ln -s "$(pwd)/doable-agent-plugins/plugins/doable-trd-context" ~/.cursor/plugins/local/doable-trd-context
 ```
 
-After Cursor Marketplace approval, install `doable-trd-context` from the marketplace or with `/add-plugin doable-trd-context`.
+Cursor Marketplace installation will replace this fallback after the plugin is approved there.
 
 ## Use
 
-Name one feature or feature domain. `Authentication` is sufficiently specific even if it includes sign-up, sign-in, and sign-out. A request such as “test the new feature” works only when the current conversation, selected PR/diff, ticket, or supplied design artifact identifies the feature. Product-wide requests are intentionally stopped before broad scanning.
-
-Useful examples:
+Ask naturally for one named feature or feature domain:
 
 ```text
 Test Authentication and prepare Doable context.
 Test the feature in this selected PR and prepare Doable context.
-Prepare Doable context for Checkout using these screenshots as desired behavior.
+Prepare Doable context for Checkout using this PRD and these screenshots.
+```
+
+A domain such as `Authentication` is specific enough even when it includes sign-up, sign-in, and sign-out. “Test the newly developed feature” also works when the conversation, selected change, ticket, or supplied artifact already identifies the feature.
+
+The plugin intentionally stops before broad repository scanning when the feature cannot be identified. Product-wide requests such as “test the whole website” require the user to choose the first feature.
+
+No prescribed long prompt, Doable API key, organization selection, suite selection, or MCP configuration is required.
+
+## How context collection works
+
+1. Identify the feature and reuse an existing local feature record when the same capability was collected before.
+2. Build a compact feature map before opening implementation details.
+3. Inspect the smallest connected evidence graph that establishes user-visible behavior, state transitions, validation, permissions, persistence, relevant tests, contracts, and cross-repo seams.
+4. Separate desired behavior, implemented behavior, deployed observations, reference material, and inference rather than silently merging them.
+5. Record the account roles, fixture states, preparation and cleanup requirements, and environment conditions needed for later testing.
+6. Validate provenance and privacy, then render one uploadable context file.
+
+Investigation depth follows the feature's actual complexity. There are no fixed time, repository-count, file-count, flow-count, or output-size limits. Before widening, the agent names the missing readiness dimension that more evidence must close; it stops repeated retrieval when it no longer adds product behavior.
+
+When the user supplies a deployment, the plugin performs at most one brief entrypoint readiness check. Reachability is recorded only as an environment fact and is never presented as verified feature behavior. The plugin does not mutate feature data or deeply test the deployment.
+
+## Multi-repo behavior
+
+Each independent Git repository is mapped separately, but the customer makes one request and receives one final context file. The agent follows only the product seams needed for the named feature and reconciles frontend, backend, contract, worker, or integration evidence into one behavioral model.
+
+An existing ownership map may accelerate orientation, but feature-relevant ownership and seams are still verified against current evidence. Repository names, paths, commits, and local topology never enter the upload.
+
+## Output and refresh
+
+The plugin writes:
+
+```text
+.doable/features/<feature-slug>/
+  doable-context.md
+  doable-intake.json
 ```
 
-The output is `.doable/features/<feature-slug>/doable-context.md`. Upload only that file. The neighboring `doable-intake.json` is local-only.
+- `doable-context.md` is the only file to upload. It contains typed **User Authority** and **Grounded Context** sections.
+- `doable-intake.json` is local canonical state for provenance, validation, refresh, and recovery. Never upload it.
 
-The normal target is a ready context in 10–12 minutes, with a 15-minute exploration stop. For features spanning one to three repositories, the Skill stays in one agent, starts from a compact feature map, and reviews evidence density when more than 24 unique source files were needed. A supplied deployment receives only one 60–90 second readiness check; reachability is never presented as verified feature behavior.
+Running the plugin again for the same feature updates the existing feature record and increments its context revision while preserving unaffected grounded content. If local history is missing, the plugin rebuilds from current evidence without pretending the lost lineage was recovered.
 
-The plugin package is `doable-trd-context`; the workflow Skill inside it is `doable-trd-intake`. Keeping those names distinct preserves compatibility with the existing Skill while making the installed package's purpose clear.
+After validation, the coding agent prints only the upload path, the next Doable step, the scope, and the collected flow names. Review is optional; no `approve` reply is required before the context is ready.
 
 ## Privacy boundary
 
-The plugin code makes no network requests and never connects to Doable. It excludes source code, repository metadata, secrets, raw logs, private URLs, and real customer data from the uploadable file. See [PRIVACY.md](PRIVACY.md) for the full boundary.
+All repository inspection stays inside the customer's coding agent. The upload excludes:
+
+- source code and snippets;
+- repository names, paths, revisions, dirty state, and evidence metadata;
+- secrets, credentials, environment values, and private URLs;
+- raw logs, attachments, and internal infrastructure topology;
+- real customer or business data.
 
-## Verify the package
+The upload may describe private product roles, behavior, fixture needs, and observable state in sanitized product language. See [PRIVACY.md](PRIVACY.md) for the complete policy.
+
+## Current limitations
+
+- One run covers one identified feature or coherent feature domain, not an entire product.
+- The user still creates a suite and uploads `doable-context.md` manually in Doable.
+- External accounts, seeded lifecycle states, callback receivers, and other fixtures are described but not provisioned.
+- Runtime reachability does not prove that repository behavior is deployed.
+- Installation remains private-beta and host marketplace availability differs.
+
+## Verify the release package
 
 ```bash
 npm test
 claude plugin validate .
 claude plugin validate ./plugins/doable-trd-context
 ```
 
-The release check verifies all three host manifests, exact Skill/schema/renderer version alignment, the Skill structure, internal references, absence of symlinks and MCP configuration, and common secret/path leaks. A context authored by an older cached Skill version fails validation and tells the agent to reload the current plugin.
+The release verifier checks host manifests, marketplace entries, exact Skill/schema/renderer version alignment, internal references, package structure, the absence of MCP configuration and symlinks, and common secret or path leaks.
+
+Use [TESTING.md](TESTING.md) for the fresh-session acceptance matrix.
+
+## Repository layout
+
+```text
+plugins/doable-trd-context/
+  .claude-plugin/
+  .codex-plugin/
+  .cursor-plugin/
+  skills/doable-trd-intake/
+```
 
-Use [TESTING.md](TESTING.md) for the fresh-session beta acceptance matrix.
+`doable-trd-context` is the installable plugin. `doable-trd-intake` is the portable workflow Skill shared by all supported hosts.
 
 ## License
 

TESTING.md

@@ -9,20 +9,23 @@ For every scenario, confirm that the agent:
 - creates one uploadable `.doable/features/<feature-slug>/doable-context.md`;
 - keeps source locations, Git revisions, dirty state, and provenance only in local `doable-intake.json`;
 - asks questions only when the answer changes scope, authority, permissions, reachability, fixture feasibility, environment alignment, or the test oracle.
-- stays in one agent for one to three relevant repositories, targets 10–12 minutes, and stops expanding at 15 minutes;
-- reviews why each extra file is needed when repository evidence exceeds the capability-adjusted target, and normally stays at or below 24 unique files;
-- limits a supplied deployment to one 60–90 second entrypoint readiness check with at most one proxy-bypassed retry after a 502, without feature mutation or deep API testing.
+- keeps discovery in one agent while the repository seams form one tractable evidence graph, delegating only independent questions that can run concurrently without duplicated orientation;
+- names the unresolved readiness dimension before widening and never treats elapsed time, repository count, file count, or output bytes as factual-completeness limits;
+- limits a supplied deployment to one brief entrypoint readiness check with at most one proxy-bypassed retry after a 502, without feature mutation or deep API testing.
+- gives a mounted orchestration/infrastructure repository a no-participation verdict unless the user identifies that stack as the target runtime, and never uploads internal cache/database/worker/container topology;
+- translates cache, transaction, row, store, service, queue, worker, and container mechanics into user-visible, re-query, persistence, no-partial-state, or asynchronous product oracles;
+- removes `doable-intake.candidate.json` only through the final successful renderer call, leaving exactly canonical local state plus the one upload.
 
 ## Positive cases
 
 1. **Named domain in a monorepo** — “Test Authentication and prepare Doable context.” Expect related sign-up, sign-in, and sign-out flows when the implementation connects them, without asking the user to enumerate routine success criteria.
 2. **Feature identified by selected change** — Select a PR or diff and say “Test the newly developed feature and prepare Doable context.” Expect the agent to derive the feature boundary from the selected change, then follow connected implementation and tests rather than scanning the full product.
-3. **Cross-repo feature** — From a workspace containing independent frontend and backend repositories, request context for one named feature such as Checkout. Expect a real repository map, a minimal seam trace, and one coherent product flow; the upload must not expose repository identities.
+3. **Cross-repo feature** — From a workspace containing independent frontend and backend repositories, request context for one named feature such as Checkout. Expect a real repository map, a minimal seam trace, disputed or dangling seams to remain explicit, and one coherent product flow; the upload must not expose repository identities. If an existing ownership map is supplied, expect it to be treated as local reference and only feature-relevant claims to be revalidated. The customer must not be asked to coordinate per-repository prompts or files.
 4. **Design artifact** — Supply a screenshot or Figma export and request one named feature. Explicitly state whether it is desired behavior, current runtime, or reference only. Expect the output to keep that truth plane separate from implemented behavior.
 5. **Same-feature refresh** — Change the implementation, then repeat the request from the same workspace. Expect the existing feature directory and stable feature ID to be reused, `contextRevision` to increment, the first request to remain unchanged, and the new request to be appended.
 6. **Executable fixtures** — Use a feature with distinct permissions or lifecycle states. Expect separate reusable fixture intents with grounded preparation and cleanup/isolation; the feature action itself must not be mislabeled as setup.
 7. **Dirty diff refresh** — Keep the same commit dirty, change one relevant modification from variant A to B, and refresh. Expect the old evidence fingerprint to fail validation until the agent semantically reviews and regenerates the affected context.
-8. **Lost local state** — Remove the feature's local `.doable` state, then request the same feature. Expect a new identity at revision 1 without fabricated history; lost lineage appears only in the completion response, not as a product unknown.
+8. **Lost local state** — Remove the feature's local `.doable` state, then request the same feature. Expect a new identity at revision 1 without fabricated history; lost lineage remains local workflow metadata, not a product unknown or normal completion-summary item.
 
 ## Guardrail cases
 
@@ -34,4 +37,4 @@ For every scenario, confirm that the agent:
 
 ## Handoff check
 
-The completion message should show the feature name, revision, short scope, bounded nonmaterial unknowns, and only the uploadable context path. It should tell the user to create a suite in Doable and upload that one file. It must not claim that a TRD, test cases, or tests were created.
+The renderer-generated completion message must contain only the uploadable context path, the instruction to create a suite and upload that file, the requested scope, and the collected flow names. It must not claim that a TRD, test cases, or tests were created, and it must not append local diagnostics or privacy boilerplate.

package.json

@@ -1,6 +1,6 @@
 {
   "name": "doable-agent-plugins",
-  "version": "0.1.2",
+  "version": "0.1.5",
   "private": true,
   "description": "Private-beta installable agent plugins for Doable.",
   "license": "MIT",

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

@@ -1,6 +1,6 @@
 {
   "name": "doable-trd-context",
-  "version": "0.1.2",
+  "version": "0.1.5",
   "description": "Prepare one privacy-safe, evidence-grounded context file for a clearly identified feature before creating a Doable TRD.",
   "author": {
     "name": "Doable AI",

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

@@ -1,6 +1,6 @@
 {
   "name": "doable-trd-context",
-  "version": "0.1.2",
+  "version": "0.1.5",
   "description": "Prepare privacy-safe, grounded context from a named feature codebase for creating a Doable TRD.",
   "author": {
     "name": "Doable AI",

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

@@ -1,7 +1,7 @@
 {
   "name": "doable-trd-context",
   "displayName": "Doable TRD Context",
-  "version": "0.1.2",
+  "version": "0.1.5",
   "description": "Prepare one privacy-safe, evidence-grounded context file for a clearly identified feature before creating a Doable TRD.",
   "author": {
     "name": "Doable AI"