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
154 changes: 143 additions & 11 deletions examples/adversarial-implementation/README.md
Original file line number Diff line number Diff line change
@@ -1,9 +1,10 @@
# Adversarial implementation

Deliver accepted work through one launch. Prepared scope facts select direct
Run implementation feedback from accepted work through one launch. Prepared scope facts select direct
implementation, ordinary planning followed by implementation, or a validated API
foundation followed by remaining consumer migration. Existing impact policy
selects independent review separately from that route.
selects internal feedback separately from that route. Delivery additionally requires
the recorded independent review and current CI.

## Applies to

Expand All @@ -17,7 +18,7 @@ change a running role's model or a live workflow's include directory.

Prepare this repository with `deno task setup`. Copy `task.example.json` to a
local file and replace its source, exact revision, output directory, accepted
request, selected evidence paths and unused session names. Prepare the selected
request, selected evidence paths, role providers, correction budgets, delivery policy and unused session names. Prepare the selected
source through its own repository instructions. Its feedback commits use its
configured Git signing and verification. Run from that source checkout:

Expand All @@ -37,6 +38,36 @@ The workflow enters the prepared checkout and artifact directory through absolut
`Dir` paths. Enable `--allow-absolute` for these runs; the flag retains existing
read/write restrictions.

## Select role providers and budgets

The launch task requires `providers` for all three original roles and explicit
`maxCorrections`, `maxApiRepairs` and `maxResponseCorrections`. For ordinary Codex
work, select:

```json
{
"providers": {"architect":"codex","planner":"codex","implementor":"codex"},
"maxCorrections": 3,
"maxApiRepairs": 3,
"maxResponseCorrections": 0
}
```

Planner and Implementor can independently select `claude` instead. The fixed
profiles below determine model and effort; provider selection never substitutes
another provider when one refuses. Architect uses `codex`. Missing or invalid
allocation or budget fields hold before paid work. The resolved Ticket manifest
retains the selected providers and all three budgets through continuation.

`maxCorrections` bounds source corrections and `maxApiRepairs` bounds
consumer-driven API repairs, each from zero through ten. `maxResponseCorrections`
bounds extra response-format calls per completed assignment, from zero through
three. Zero admits no extra response call. It applies to ordinary planning,
implementation, selected feedback reviews and foundation replies, including
repairs by their original owner. It authorizes no transport retry or repetition
of uncertain productive work. Continuing a Ticket keeps its consumed source
correction count and recorded allocation; it does not restart a failed attempt.

## Prepare scope and impact

All four closed scope groups are required. Their evidence arrays name nonempty,
Expand Down Expand Up @@ -134,6 +165,106 @@ The roles use the normal agent permission policy. Running this example invokes
paid coding agents and permits the assigned implementation work. Publication,
issue/PR metadata and delivery remain with the Sidekick running Codex.

## Complete delivery from recorded requirements

Use this after implementation feedback, for ordinary runs and REPL entries.
`feedback_ready` establishes the selected internal feedback; it leaves independent
review, required CI and current main health outstanding. `run.md` requires a
`delivery` declaration before any role starts and writes its original captured
acceptance text to `delivery/requirements.json`. A missing declaration refuses
launch. Clause IDs are distinct and each source selects an original `task.inputs`
reference. The independent reviewer uses a separate conversation from all three
implementation roles.

Publish the branch and draft PR through the existing owner, then run from the
same source checkout:

```bash
xmd run --allow-absolute /absolute/path/to/workflow/examples/adversarial-implementation/delivery.md \
--props-record /absolute/work/fresh-bounded-parser-fix/delivery/requirements.json \
--props-number 123 --props-action status \
--include /absolute/path/to/workflow/examples/adversarial-implementation/components --raw
```

`status` starts no model. It reads the saved joined review, the current PR and
GitHub's CI workflow runs. Its `nextAction` is computed from the same facts as
its `status` and `remaining` fields. When it requests `review`, select
`--props-action review` on that command to perform one independent review with
the provider, model, effort and session recorded at launch. Prepare the installed
client for that model beforehand; a provider refusal retains its original
attempt and grants no fallback. The review uses normal coding-agent permissions.
It receives the original captured acceptance text and may inspect source and run
focused checks; it receives no implementation, delegation, posting or merge task.

```text
feedback pending -> continue original feedback
feedback ready -> independent review pending -> joined exact-commit verdict
| incomplete/uncertain -> reconcile original call
| blocking finding -> request approved repair
| pass + required CI + main -> finish PR metadata
| all passed + PR ready -> await authorized merge
| confirmed merge -> delivered
```

A complete review covers every recorded clause and has no blocking finding.
The component writes its completion receipt after the role operation has returned
and its scope has unwound. Status compares that receipt with the actual saved
execution reply, reviewer configuration and acceptance clauses. A matching JSON
summary alone supplies none of this correspondence. An occupied attempt is held
for reconciliation, including a failure before a result or receipt exists; a
second invocation never repeats that model call automatically. A new source
commit requires matching implementation feedback and independent review. A
repair keeps the original conversations and its separately approved correction
allowance; this entry grants no repair round.

The PR must name the checkout's exact current commit and branch with base main.
Readback checks the PR and main heads again after the remote reads, and checks
the checkout again. CI selection follows the highest run number and attempt for
the requested PR, its exact head commit and head branch, and requires that attempt's
actual `green` job to succeed. Missing PR association supplies no passing evidence.
Main health reuses the repository's authoritative selection
rule for a push to main's exact current head. Pending, cancelled, skipped and
failed runs cannot pass. The maintainer-applied `ci-main-red-fix` exception keeps
the repository's CI contract: it substitutes composability for the main lookup
inside CI. A draft PR remains `publication_pending`; only a confirmed merge with
a merge commit reports `delivered`. Refresh status before acting on readiness.

The saved `status.json` is the last observation, not a second execution state.
Use the command for a current answer. Local records are trusted workflow
artifacts, not signatures or remotely verifiable attestations. GitHub does not
read them, and this gate does not prevent an arbitrary chat message or a person
from claiming readiness or merging independently.

## Prepare requests without metadata repair turns

These rules apply to separate phase requests and Ticket role calls.
`Phase.Request` renders the complete prompt before entering an Agent, including
initial repository instructions, role instructions, assignment, selected text and
response schema. A missing selected component or input fails there; a packet
above 256000 characters refuses before provider dispatch. The selected evidence
keeps its separate 64000-character bound; the complete-prompt ceiling also accommodates
mandatory initialization instructions and the response schema. Nothing is truncated.
Provider configuration and client compatibility retain their existing checks before a turn starts.
No paid prompt probes installation or repairs launch metadata.

`Phase.Response` supplies omitted phase and work from the assignment, and the
assigned revision for a read-only phase. It supplies the accepted continuation
for complete/pass. Explicit conflicting fields remain errors. The Implementor
still supplies its actual resulting commit, and every role supplies its real
verdict, findings and evidence. The existing zero-response-correction option
continues to validate and retain a reply at zero; missing substantive facts are
never synthesized to make a reply pass.

Acceptance clauses preserve their original source and wording through delivery.
A reviewer reports a material ambiguity as blocked instead of strengthening a
criterion. This records traceability; it does not mechanically decide whether two
natural-language requirements mean the same thing.

Submission-owned progress and joined entry completion remain separate work in
[#1062](https://github.com/taras/executable.md/issues/1062). Fatal entry outcome
diagnostics remain [#1059](https://github.com/taras/executable.md/issues/1059).
Neither is replaced by the delivery status file or an attachment observer.

## Run a separate phase or continue a saved ticket

Use these entries from the workflow repository when coordinating a separate
Expand Down Expand Up @@ -205,6 +336,7 @@ omitted. A direct REPL invocation uses the same option:
<Phase.Run phase={request.assignment.phase} role={request.role}
session={request.session} assignment={request.assignment} attempt={request.attempt}
initialize={request.initialize ?? false} inputs={Object.values(documents)}
plannerProvider={request.plannerProvider ?? "claude"}
implementationProvider={request.implementationProvider ?? "claude"}
maxResponseCorrections={0} successor={request.assignment.continuation.phase}
nextRole={request.assignment.continuation.role} as="phase" />
Expand Down Expand Up @@ -246,14 +378,14 @@ determine the work's outcome.

| Owner | Work | Model and effort |
| --- | --- | --- |
| Planner | Ordinary plan/evidence; on migration, implement the API, validate representative consumers and repair API conflicts | Claude `opus`; ordinary planning uses ReviewPolicy effort: medium, high for a concrete recorded risk; migration foundation design uses high |
| Implementor | Implement accepted work; on migration, challenge the API, convert consumers and delete obsolete machinery | Claude `sonnet`, high |
| Planner reviewer | Inspect the migration against the accepted outcome and evidence | Same Opus session, medium; high for a concrete recorded risk |
| Planner | Ordinary plan/evidence; on migration, implement the API, validate representative consumers and repair API conflicts | Selected Codex `gpt-6.1-sol` or Claude `opus`; ordinary planning uses medium, high for a concrete recorded risk; migration foundation design uses high |
| Implementor | Implement accepted work; on migration, challenge the API, convert consumers and delete obsolete machinery | Selected Codex `gpt-6.1-sol`, medium (high for a concrete recorded risk), or Claude `sonnet`, high |
| Planner reviewer | Inspect the migration against the accepted outcome and evidence | Same selected provider and original Planner session, medium; high for a concrete recorded risk |
| Architect | Answer a concrete structural question or review structural impact | Codex `gpt-6.1-sol`, medium; high for a concrete recorded risk |
| Sidekick running Codex | Author and apply issue/PR titles and descriptions; own publication and delivery | Existing coordinating Sidekick |

Aliases select the provider's available Opus and Sonnet models. The two Claude
roles do not draft or edit issue/PR titles or descriptions. The phase runner
Aliases select the provider's available Opus and Sonnet models. Coding roles
do not draft or edit issue/PR titles or descriptions. The phase runner
refuses editorial assignments; technical handoffs and API documentation remain
part of the roles' work.

Expand Down Expand Up @@ -304,7 +436,7 @@ reply and diagnostics. Schema matching never chooses between candidates.

When the only invalid fields are an oversized summary or handoff, foundation
response correction can shorten those fields in the same Planner session, at
most three times. Every other field is frozen, including the API, source,
most `task.maxResponseCorrections` times. Every other field is frozen, including the API, source,
assessment and evidence. Each correction saves its request, raw reply and
disposition, and checks that source remains at the same clean commit. The
productive assignment is not repeated. An ambiguous or substantively invalid
Expand All @@ -323,8 +455,8 @@ provider failure, malformed response, unanswered decision or exhausted bound
holds with saved evidence. It does not trigger an uncertain prompt retry.

`maxApiRepairs` bounds consumer-driven API repairs; `maxCorrections` bounds the
existing implementation-review corrections. Both default to three and accept
zero through ten. Repeated redesign is evidence that the split is not paying
existing implementation-review corrections. Both are explicit launch inputs and
accept zero through ten. Repeated redesign is evidence that the split is not paying
for itself: inspect the saved consumer conflicts before extending either bound.

The imported feedback loop retains impact-selected reviews, bounded response
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -11,10 +11,10 @@ props:
---

<Adversarial.Schema as="schemas" />
<Phase.Profile role="planner" design={true} assessment={props.assignment.assessment} as="profile" />
<Output><Agent name="claude"><Session name={props.assignment.session} model={profile.model} effort={profile.effort}><Prompt throwOnError={true}>
<Phase.Profile role="planner" design={true} plannerProvider={props.assignment.plannerProvider} assessment={props.assignment.assessment} as="profile" />
<Output><Agent name={profile.provider}><Session name={props.assignment.session} model={profile.model} effort={profile.effort}><Prompt throwOnError={true}>
<If condition={props.correction !== null}>
You remain the original Planner. This is response-only correction {props.correction.ordinal} of three. Shorten only the rejected summary or handoff to its stated bound. Every other result value is frozen by the supplied schema, including the API, outcome, source revision, artifacts, assessment and command evidence.
You remain the original Planner. This is response-only correction {props.correction.ordinal} with {props.correction.remaining} remaining. Shorten only the rejected summary or handoff to its stated bound. Every other result value is frozen by the supplied schema, including the API, outcome, source revision, artifacts, assessment and command evidence.

Perform no implementation, command execution, test, signing, publication or other productive work. Do not repeat the earlier assignment. Return only the corrected JSON result. If the existing facts cannot satisfy the schema, preserve that uncertainty; do not invent evidence.

Expand All @@ -29,6 +29,8 @@ Repository instructions:
Role instructions:
{props.guide}
</If>
Use the provider, model and effort explicitly selected by this workflow; historical role-guide defaults do not replace that allocation.

Continue in the same Planner conversation. Use the supplied inputs and prior API evidence; investigate a specific missing fact instead of repeating discovery. A repair preserves the original accepted outcome and completed migration work.

Do not draft, create or edit PR or issue titles or descriptions. The Sidekick running Codex authors and applies that metadata. Return technical artifacts and evidence; API usage documentation remains your responsibility.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,7 @@ returns: {type: object}
<If condition={!established.ok}><Fail message="No unambiguous substantive foundation result is established. Preserve raw.txt and response-rejection-0000.json; no productive prompt is repeated." /></If>
<Let as="frozen" value={{...schemas.foundation,properties:Object.fromEntries(Object.entries(schemas.foundation.properties).map(([key,schema]) => [key,(key === "summary" || key === "handoff") && established.value[key].length > schema.maxLength ? schema : {const:established.value[key]}]))}} />
<Loop max={3}>
<If condition={checked.ok}><Break /></If>
<If condition={checked.ok || round >= props.assignment.maxResponseCorrections}><Break /></If>
<Let as="round" value={round + 1} />
<Let as="directory" value={props.assignment.attempt + "/response-corrections/" + round} />
<Dir path={props.assignment.attempt + "/response-corrections"}><Let as="parentPrepared" value={true} /></Dir>
Expand All @@ -36,7 +36,7 @@ returns: {type: object}
mkdir -- {quoted}
```
<If condition={reserved.exitCode !== 0}><Fail message="Preserve the occupied response correction; do not repeat its prompt." /></If>
<Let as="packet" value={{ordinal:round,remaining:3-round,raw:rawPath,rejection:checked.errors,established:established.value,resultSchema:frozen}} />
<Let as="packet" value={{ordinal:round,remaining:props.assignment.maxResponseCorrections-round,raw:rawPath,rejection:checked.errors,established:established.value,resultSchema:frozen}} />
<If condition={JSON.stringify(packet).length > 64000}><Fail message="The response correction packet exceeds its input bound; preserve it without dispatch." /></If>
<Dir path={directory}><File path="request.json"><Json value={packet} /></File></Dir>
<Ticket.Checkout repository={props.assignment.repository} as="before" />
Expand Down Expand Up @@ -64,6 +64,9 @@ git status --porcelain=v1 --untracked-files=all
<If condition={extracted.ok}><SafeParse schema={frozen} as="checked">{extracted.json}</SafeParse></If>
<Dir path={directory}><File path="disposition.json"><Json value={{round,accepted:checked.ok,raw:rawPath,errors:checked.ok ? [] : checked.errors}} /></File></Dir>
</Loop>
<If condition={!checked.ok}><Fail message="Three response-only corrections are exhausted. Preserve their receipts; no productive prompt is repeated." /></If>
<If condition={!checked.ok}>
<Dir path={props.assignment.attempt}><File path="response-disposition.json"><Json value={{status:"failed_without_result",dispatchable:false,consumed:round,limit:props.assignment.maxResponseCorrections}} /></File></Dir>
<Fail message="The selected response-only correction budget is exhausted. Preserve its receipts; no productive prompt is repeated." />
</If>
</If>
<Return value={{result:checked.value,round,rawPath}} />
Loading
Loading