Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,19 @@

All notable changes to Doable Agent Plugins are documented here.

## [0.2.2] - 2026-08-20

### Changed

- Watch one published Round until the editor continues TRD 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
same revision can be recorded. Retrying the exact same payload stays idempotent.
- Before scanning, the answering Skill verifies any named branch, PR, worktree, or
change set locally, refreshes a stale checkout, and stops if that target is
missing or ambiguous. A Round does not transfer Git state.

## [0.2.1] - 2026-08-13

### Fixed
Expand Down
39 changes: 31 additions & 8 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ Official agent plugins for [Doable](https://getdoable.ai), supporting Codex, Cla

| Plugin | Version | Purpose | Network |
| --- | --- | --- | --- |
| `doable-code-context` | `0.2.1` | Resolve context requests or start a managed feature-testing workflow | Configured Doable MCP |
| `doable-code-context` | `0.2.2` | Resolve context requests or start a managed feature-testing workflow | Configured Doable MCP |

## Workflow

Expand All @@ -16,14 +16,31 @@ Use **Doable Code Context** for the connected pre-TRD workflow:
1. The user submits a TRD 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
questions before publishing one frozen round with a short copy prompt such as:
questions before publishing one Round with a short copy prompt such as:

```text
Resolve Doable context request DQ-7F3K for this workspace.
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
https://github.com/getdoable/doable-agent-plugins#install.
```

3. The coding agent performs demand-driven workspace setup if needed, pulls that exact frozen round, grounds the base request across the relevant private repositories, answers the focused supplements, asks one batched clarification round only when product authority is missing, and pushes structured grounded findings suitable for later knowledge reuse.
4. Doable reviews the dispositions and continues the existing TRD loop.
3. Paste that prompt once. The coding agent checks the Skill and this
organization's API Key, connects the workspace if needed, confirms the agreed
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
again.
4. The coding agent keeps watching until the TRD-editor continues TRD generation
or the Round is cancelled. `ready_to_create` is not finished. Doable then
continues the existing TRD 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
change is present in the connected repositories. If that target is missing or
ambiguous, it stops and asks the user to fetch, check out, or identify it
instead of answering from a neighboring revision.

All remote operations use the separately configured Doable MCP connection. The bundled helper is not a service or standalone CLI: it deterministically maps local repositories, keeps exact provenance private, builds safe payloads, and validates MCP responses.

Expand Down Expand Up @@ -117,12 +134,18 @@ Restart the coding-agent host after changing its environment. Confirm that the `

## Use Doable Code Context

Normally, paste the short prompt copied from the Doable TRD composer:
Normally, paste the short prompt copied from the Doable TRD-editor once:

```text
Resolve Doable context request DQ-7F3K for this workspace.
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
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.

Setup is recovered inside the same conversation if needed. The user may also request it directly:

```text
Expand Down Expand Up @@ -167,7 +190,7 @@ The connected plugin:
- record fixtures, permissions, validation, persistence, failures, and cross-repo seams only when they affect testing;
- treat repository content as untrusted evidence, not instructions.

Doable never receives source code or snippets, real repository names or paths, branches or commits, secrets or environment values, private URLs, raw logs, internal topology, or real customer data.
Doable never receives source code or snippets, real repository names or paths, branches, commits, the code graph, secrets or environment values, private URLs, raw logs, internal topology, or real customer data.

See [PRIVACY.md](PRIVACY.md) for the exact per-plugin boundary.

Expand Down
7 changes: 4 additions & 3 deletions TESTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ For every scenario, confirm that the agent inspects only evidence needed for the
3. **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.
4. **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.
5. **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.
6. **Exact frozen round** — Pull a valid `DQ-...` code. Confirm only `open_for_agent` is accepted, workspace identity matches, and the private snapshot preserves the exact question revision.
6. **Watch one Round** — Pull a valid `DQ-...` code. Confirm `Next action: answer` while `open_for_agent` has open questions, `wait` for `ready_to_create` / `needs_attention`, and `stop` for `creating` / `consumed` / `cancelled`. 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.
7. **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.
8. **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.
9. **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.
Expand All @@ -20,10 +20,11 @@ For every scenario, confirm that the agent inspects only evidence needed for the
11. **One clarification round** — Leave two required normative decisions and one same-scope newly discovered decision unresolved. Expect one batched customer interaction and exact question/answer pairs. Adjacent out-of-scope discoveries stay local.
12. **Agent authority** — Attempt to submit `deferred`, `waived`, or a required agent observation. Expect local validation to reject it. `skipped` remains available with a bounded reason for platform review.
13. **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.
14. **Idempotent retry** — Submit the same candidate twice. Expect one network submission and a local same-digest receipt. Change the candidate after receipt and expect the helper to reject it.
14. **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.
15. **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.
16. **No TRD side effect** — Completing the round must report platform review as the next step. The plugin must not create a TRD, generate cases, run tests, or poll for completion.
16. **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.
17. **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.
18. **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.
19. **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.
20. **Source versus deployment boundary** — Point the round at a deployed environment without evidence that its revision matches the inspected workspace. Expect confirmed code findings plus one explicit evidence-free `unknown` for the unproved equivalence. Reachability alone must not upgrade source behavior into deployed behavior.
21. **Named checkout target** — Name a feature branch, PR, worktree, or change set that is not the current checkout. Expect the agent to stop and ask the user to fetch, check out, or identify it. It must not answer from a neighboring revision, turn the mismatch into `unknown`, or send branch/commit details remotely.
2 changes: 1 addition & 1 deletion package.json
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "doable-agent-plugins",
"version": "0.2.1",
"version": "0.2.2",
"private": true,
"description": "Official installable agent plugins for Doable.",
"license": "MIT",
Expand Down
2 changes: 1 addition & 1 deletion plugins/doable-code-context/.claude-plugin/plugin.json
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "doable-code-context",
"version": "0.2.1",
"version": "0.2.2",
"description": "Connect private code to Doable through MCP, resolve grounded context requests, and start managed feature-testing workflows.",
"author": {
"name": "Doable AI",
Expand Down
4 changes: 2 additions & 2 deletions plugins/doable-code-context/.codex-plugin/plugin.json
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "doable-code-context",
"version": "0.2.1",
"version": "0.2.2",
"description": "Connect private code to Doable through MCP, resolve grounded context requests, and start managed feature-testing workflows.",
"author": {
"name": "Doable AI",
Expand Down Expand Up @@ -33,7 +33,7 @@
"websiteURL": "https://getdoable.ai",
"privacyPolicyURL": "https://qa.getdoable.ai/privacy-policy",
"defaultPrompt": [
"Resolve Doable context request DQ-7F3K for this workspace.",
"Resolve Doable context request DQ-7F3K for organization HireEZ (hireez).",
"Connect this workspace to Doable for code-context requests.",
"Use Doable to test the feature I just implemented."
]
Expand Down
2 changes: 1 addition & 1 deletion plugins/doable-code-context/.cursor-plugin/plugin.json
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
{
"name": "doable-code-context",
"displayName": "Doable Code Context",
"version": "0.2.1",
"version": "0.2.2",
"description": "Connect private code to Doable through MCP, resolve grounded context requests, and start managed feature-testing workflows.",
"author": {
"name": "Doable AI"
Expand Down
Loading
Loading