devflow-engine 1.0.0__py3-none-any.whl

devin/nodes/intake/prompt.md

@@ -0,0 +1,12 @@
+# Devin Intake Routing Doctrine
+
+Determine which Devin arm should handle the current turn.
+
+- `ideation`: software/product shaping, feature requests, workflow design, implementation planning, readiness clarification, or “build/change/add/fix this in the project” requests.
+- `insight`: project-specific questions about code, repo state, queue status, worker state, architecture, behavior, operations, or “what is happening / how does this work?” questions.
+
+Routing rules:
+- Prefer `insight` for repo/operations/status questions.
+- Prefer `ideation` for forward-looking product/build requests.
+- If the user asks for planning/refinement of a software change, keep it in `ideation`.
+- If the user asks for explanation/investigation of the current system, keep it in `insight`.

devin/nodes/intake/scenarios/ideation_routing.py

@@ -0,0 +1,4 @@
+SCENARIO_NAME = 'ideation_routing'
+SCENARIO_DESCRIPTION = 'Routes a forward-looking software feature request into the ideation arm.'
+INPUT_PAYLOAD = {'raw_text': 'Build a client portal that lets staff triage support requests and track approvals.'}
+EXPECTED_BEHAVIOR = {'route_arm': 'ideation', 'reason_contains': 'software'}

devin/nodes/intake/scenarios/ideation_routing_evals.py

@@ -0,0 +1,5 @@
+EVAL_CRITERIA = {'route_arm_must_equal': 'ideation'}
+
+def evaluate(actual_output: dict) -> tuple[bool, list[str]]:
+    ok = actual_output.get('route_arm') == 'ideation'
+    return ok, ([] if ok else ['expected ideation route'])

devin/nodes/intake/scenarios/insight_routing.py

@@ -0,0 +1,4 @@
+SCENARIO_NAME = 'insight_routing'
+SCENARIO_DESCRIPTION = 'Routes a repo/operations question into the insight arm.'
+INPUT_PAYLOAD = {'raw_text': 'What is the source-doc queue status for this project right now?'}
+EXPECTED_BEHAVIOR = {'route_arm': 'insight', 'reason_contains': 'operational'}

devin/nodes/intake/scenarios/insight_routing_evals.py

@@ -0,0 +1,5 @@
+EVAL_CRITERIA = {'route_arm_must_equal': 'insight'}
+
+def evaluate(actual_output: dict) -> tuple[bool, list[str]]:
+    ok = actual_output.get('route_arm') == 'insight'
+    return ok, ([] if ok else ['expected insight route'])

devin/nodes/iterate/README.md

@@ -0,0 +1,44 @@
+# Iterate node design scaffold
+
+This directory is the design home for the proposed Devin `iterate` arm.
+
+It now reflects Marcus's preferred agent-development pipeline explicitly:
+
+1. objectives and requirements
+2. evals
+3. tools and boundaries
+4. harness and playground
+5. prompt deferred until the first four stages are accepted
+
+## Directory map
+
+- `contract.md` , top-level iterate contract, routing boundary, and orchestration shape
+- `artifacts.md` , shared artifact contracts across the iterate lane
+- `agent-roles.md` , high-level accountability split for Iterator, Framer, Observer, and Coder
+- `pipeline/` , cross-agent design docs ordered by development stage
+- `agents/` , per-agent design docs, each ordered by development stage
+- `eval-plan.md` , consolidated eval inventory spanning routing, framing, observation, supervision, and completion truth
+- `playground-contract.md` , lane-level harness and fixture contract
+- `scenarios/` , planning docs for future scenario fixtures and eval implementations
+
+## Design rules for this directory
+
+- Design only, no implementation code
+- No real prompt content yet
+- Objectives lead, non-goals derive from objectives
+- Evals come before tool affordances
+- Tools are documented as bounded capabilities, not as permission theater
+- Harness design tests contracts and truthfulness, not just style
+
+## Current recommended orchestration
+
+- pattern: advisor-primary
+- primary owner: `Iterator`
+- advisors: `Framer`, `Observer`
+- supervised worker: `Coder`
+
+The intent is one accountable owner with specialist artifacts constraining the coding loop, not a flat peer swarm.
+
+## Prompt status
+
+Prompt authoring is intentionally deferred. See `pipeline/05-prompt-deferred.md` for the acceptance rule.

devin/nodes/iterate/__init__.py

@@ -0,0 +1 @@
+"""Iterate node package."""

devin/nodes/iterate/_archived_design_stages/01-objectives-requirements.md

@@ -0,0 +1,112 @@
+# Iterate objectives and requirements
+
+## Why this stage exists
+
+This is stage 1 in Marcus's iterate design order:
+1. objectives and requirements
+2. evals
+3. tools and boundaries
+4. harness and playground
+5. prompt content only after the first four stages are stable
+
+If this file is vague, every later stage will drift. The point here is to lock the lane objective, routing boundary, role ownership, and completion requirements before anyone talks about tools or prompt wording.
+
+## Lane objective
+
+`iterate` owns a bounded change request on an existing surface and carries it from messy ask to one of three truthful outcomes:
+- verified completion
+- honest blocked verdict
+- explicit promotion out of iterate
+
+This lane is for task-scale execution, not for read-only diagnosis and not for broad product planning.
+
+## What must be true for a request to belong in iterate
+
+A request belongs in `iterate` only when all of these are plausibly true:
+- the user wants a change, not just an explanation
+- the target is an existing surface, behavior, or failure
+- the work can be framed as a bounded task artifact
+- success can be checked by a scoped observation seam or equivalent proof
+- the change does not require new planning truth at story or feature scale
+
+If any of those fail, routing should change instead of forcing the work through iterate.
+
+## Routing requirements
+
+### Route to `iterate`
+Route to `iterate` when the ask is a targeted fix, quick change, or narrow improvement against an existing route, page, component, workflow step, API behavior, or failure mode.
+
+### Route to `insight`
+Route to `insight` when the user wants investigation, explanation, diagnosis, or read-only analysis without asking for implementation.
+
+### Route to `idea`
+Route to `idea` when framing reveals that the work is no longer task-scale, needs new product or workflow planning, or cannot be truthfully described as a bounded delta on an existing surface.
+
+### Re-route during execution
+Initial routing is not permanent. If Framer or Observer discovers that the task is actually read-only or broader-planning work, Iterator must re-route honestly instead of preserving the original lane choice for convenience.
+
+## Truth requirements
+
+### Task truth before coding
+A coding attempt requires a bounded `task_artifact` with:
+- current behavior
+- desired behavior
+- explicit success criteria
+- known scope boundary
+- blocking unknowns called out separately from assumptions
+
+### Observation truth before completion
+A completion claim requires an `observation_artifact` that establishes one of these:
+- a confirmed repro that later stops reproducing, or
+- a bounded red-to-green verification seam for the requested improvement
+
+### Honest uncertainty
+If evidence is missing, repro cannot be confirmed, or the green condition is weak, the lane must say that plainly. Missing truth is a blocker signal, not a reason to improvise confidence.
+
+## Supervision requirements
+
+### Iterator is the accountable owner
+`Iterator` owns lane judgment, readiness to code, respawn decisions, routing changes, and final disposition.
+
+### Framer and Observer constrain the loop
+`Framer` and `Observer` are not optional flavor agents. Their artifacts are the contract that bounds what `Coder` is allowed to do and what `Iterator` is allowed to approve.
+
+### Coder stays subordinate to artifacts
+`Coder` implements the scoped delta and reports evidence. `Coder` does not redefine scope, success criteria, readiness, or completion truth.
+
+## Scope requirements
+
+The iterate lane must:
+- stay at task scale
+- name the affected surface as concretely as possible
+- expose scope growth immediately
+- prefer blocked or promoted verdicts over fake completion
+- resist unrelated cleanup, opportunistic refactors, or stealth feature work
+
+## Required shared artifacts
+
+The lane contract depends on four shared artifacts:
+- `task_artifact`, authored by Framer and approved for use by Iterator
+- `observation_artifact`, authored by Observer and used by Iterator as the truth seam
+- `iterator_run`, owned by Iterator with coder attempts recorded inside it
+- `promotion_handoff`, authored by Iterator only when work exits iterate for `idea` or `insight`
+
+These artifacts are the cross-agent operating contract. If an important judgment is not grounded in one of them, the design is underspecified.
+
+All durable top-level iterate artifacts should use monotonic integer revisions so readiness and promotion decisions can point to concrete artifact revisions rather than vague "latest" state.
+
+## Role ownership summary
+
+- `Iterator` owns route fit, readiness, supervision, respawn logic, and final verdict
+- `Framer` owns bounded task construction and promotion recommendations discovered during framing
+- `Observer` owns evidence, repro, green-condition definition, and coding-readiness recommendation
+- `Coder` owns implementation attempts and narrow verification execution under supervision
+
+## Minimum acceptance bar for moving to stage 2
+
+This stage is ready for eval design only when reviewers can answer all of these clearly:
+- what counts as iterate versus insight versus idea
+- what artifact truth must exist before coding starts
+- what completion evidence Iterator is allowed to trust
+- what each of the four agents owns and must not absorb
+- what conditions force blockage or promotion instead of completion

devin/nodes/iterate/_archived_design_stages/02-evals.md

@@ -0,0 +1,131 @@
+# Iterate evals by pipeline stage
+
+## Purpose
+
+This is stage 2 in Marcus's iterate design order. Its job is to prove that the stage-1 contract is testable before anyone specifies tools, harnesses, or prompts.
+
+A good eval here answers: "what concrete failure would tell us this iterate design is lying, drifting, or collapsing ownership boundaries?"
+
+## Eval design rules
+
+Every eval in this file should check contract truth, not style.
+
+That means evals should prefer:
+- routing correctness over eloquent justification
+- artifact quality over generic helpfulness
+- ownership discipline over agent enthusiasm
+- truthful blocked or promoted outcomes over forced completion
+
+## Eval buckets
+
+### 1. Route selection evals
+These test whether intake and re-routing keep iterate limited to bounded change work.
+
+Must pass examples:
+- a concrete existing-surface bug fix routes to `iterate`
+- a small behavior tweak routes to `iterate`
+- a narrow UI improvement on an existing page routes to `iterate`
+
+Must reject examples:
+- investigation-only asks route to `insight`
+- explanation-only asks route to `insight`
+- broad feature or workflow requests route to `idea`
+- initially small asks that expand during framing are promoted out of `iterate`
+
+Failure signals:
+- `iterate` absorbs read-only diagnostic work
+- `iterate` absorbs broad planning work
+- lane choice is treated as irreversible after better truth appears
+
+### 2. Task artifact integrity evals
+These test Framer's ability to convert a messy ask into a bounded contract.
+
+Required checks:
+- the artifact identifies current behavior and desired behavior distinctly
+- success criteria are observable and not aspirational
+- scope is narrow enough for task-scale execution
+- assumptions are separated from facts
+- blocking unknowns are separated from nonblocking unknowns
+- a promotion recommendation appears when framing reveals non-iterate scope
+- task artifact revisions increase monotonically when framing is amended
+
+Failure signals:
+- task artifact reads like a vague restatement of the user message
+- success criteria cannot be verified later by Observer or Iterator
+- scope is so broad that Coder would need to reinterpret the task
+
+### 3. Observation artifact integrity evals
+These test whether Observer creates a truthful seam for implementation and validation.
+
+Required checks:
+- evidence is grounded in logs, repro steps, failing seam output, or equivalent observable proof
+- the artifact can report `not_confirmed` honestly when repro fails
+- repeatability status is explicit
+- expected green condition is concrete enough for Iterator to validate later
+- missing evidence triggers a context request or blocked recommendation, not invented certainty
+- observation artifact revisions increase monotonically when new truth is learned
+
+Failure signals:
+- repro is implied but not documented
+- evidence summary has no traceable source
+- green condition is too vague to distinguish success from partial progress
+
+### 4. Supervision integrity evals
+These test whether Iterator preserves the advisor-primary model.
+
+Required checks:
+- Iterator refuses to start coding before task and observation artifacts are sufficient
+- Iterator uses Framer and Observer outputs as constraints, not as optional suggestions
+- Iterator respawns Coder only with repair-specific context tied to the artifacts
+- Iterator blocks or promotes when truth or scope no longer fits iterate
+- promotion or reroute writes an iterate-owned handoff artifact with references back to the exact task and observation revisions used for the decision
+
+Failure signals:
+- Iterator bypasses missing artifact truth because coding "might help"
+- Iterator lets Coder redefine the task, evidence, or completion bar
+- Iterator returns completion after scope drift
+
+### 5. Coder discipline evals
+These test whether Coder behaves like a supervised worker instead of a peer decider.
+
+Required checks:
+- implementation stays within the bounded task and named surface
+- verification stays narrow and relevant to the observation seam
+- attempt reports say what changed, what passed, what failed, and what remains blocked
+- second attempts respond to repair context rather than restarting from scratch conceptually
+
+Failure signals:
+- unrelated refactors or cleanup appear without authorization
+- Coder claims success without matching the artifact green condition
+- Coder silently broadens the solution to compensate for poor framing
+
+### 6. Completion integrity evals
+These test the final truth gate.
+
+Required checks:
+- no completion without a green seam or equivalent scoped proof
+- no completion when requested user-visible behavior is still missing
+- no completion when the observed failure still reproduces
+- no completion after unauthorized scope growth
+- blocked verdicts are allowed and scored as correct when truth is insufficient
+- promotion verdicts are allowed and scored as correct when the task has become planning work
+
+Failure signals:
+- the system rewards optimistic claims over truthful disposition
+- completion can happen without evidence that corresponds to the original ask
+
+## Cross-agent eval expectations
+
+The four-agent model should be explicitly visible in eval coverage:
+- `Framer` evals prove task-bounding quality
+- `Observer` evals prove evidence and green-condition quality
+- `Coder` evals prove implementation discipline
+- `Iterator` evals prove ownership of readiness, supervision, and final judgment
+
+If a behavior matters but cannot be assigned to one of those owners, the contract is still blurry.
+
+## Review rule
+
+A stage-1 requirement is not real until there is a plausible eval that could fail it.
+
+If reviewers cannot describe how a bad route, bad artifact, bad supervision choice, or fake completion would be caught, the iterate design is not ready to advance to stage 3.

devin/nodes/iterate/_archived_design_stages/03-tools-and-boundaries.md

@@ -0,0 +1,110 @@
+# Iterate tools and boundaries
+
+## Purpose
+
+This is stage 3 in Marcus's iterate design order. By the time this file is written, the lane objective and eval expectations should already be stable.
+
+The point here is not to list every possible runtime permission. The point is to define which capability classes each role needs in order to satisfy the stage-1 and stage-2 contract, and which capability classes would let that role collapse into another role.
+
+## Tooling principle
+
+Describe capabilities in responsibility terms, not vendor or provider terms.
+
+Good examples:
+- repo inspection
+- log and trace inspection
+- bounded test execution
+- artifact read and write
+
+Bad examples:
+- naming a provider-specific tool without explaining which contract requirement it serves
+- granting broad execution rights to compensate for unclear ownership
+
+## Shared lane capability classes
+
+The iterate lane as a whole needs access to these capability classes:
+- conversation and history reading
+- repository and project surface inspection
+- logs, traces, screenshots, and repro surfaces when relevant
+- artifact read and write surfaces
+- narrow verification seam execution
+- supervised implementation execution
+
+These are lane-level needs. They are not automatically granted to every role equally.
+
+## Role capability boundaries
+
+### Iterator
+Needs:
+- read access to conversation context and shared artifacts
+- enough inspection capability to judge route fit, readiness, and final evidence
+- authority to spawn or supervise Coder
+- write access to iterator-owned run records, monotonic revision updates, promotion handoff records, and final disposition
+
+Must not become:
+- the default implementation worker
+- the substitute observer who handwaves missing evidence
+- the substitute framer who rewrites the task mid-loop to make an attempt look successful
+
+### Framer
+Needs:
+- conversation and history reading
+- project and surface inspection sufficient to localize the ask
+- artifact write access for `task_artifact`
+
+Must not have responsibility for:
+- running broad repro or verification work that belongs to Observer
+- implementation execution
+- final completion judgment
+
+### Observer
+Needs:
+- evidence-source inspection such as logs, traces, screenshots, and repo context
+- bounded repro execution and narrow red-seam creation
+- artifact write access for `observation_artifact`
+
+Must not have responsibility for:
+- silently editing code to make repro disappear
+- redefining task scope
+- returning final completion on behalf of Iterator
+
+### Coder
+Needs:
+- repository read and write access within the supervised work area
+- implementation execution capability
+- narrow verification execution aligned to the task and observation seam
+- ability to append implementation and verification notes to the run record
+
+Must not have responsibility for:
+- changing route classification
+- redefining success criteria
+- deciding that missing evidence is good enough
+- writing the final verdict as if implementation were the same thing as truth
+
+## Boundary rules that should survive runtime implementation
+
+- missing evidence should trigger context requests, blockage, or promotion, not bluffing
+- missing task clarity should trigger framing repair, not coder improvisation
+- scope growth should trigger promotion review, not quiet expansion of the task
+- read-only user intent should route to `insight`, even if implementation would be easy
+- artifact revisions should advance explicitly when durable top-level truth changes, rather than relying on implicit last-write-wins semantics
+- only Iterator should stamp promotion linkage or write `promotion_handoff.json`
+- provider convenience must not override role boundaries
+
+## Practical anti-collapse checks
+
+A tools design is probably wrong if any of these become normal:
+- Iterator frequently edits code directly because it is faster
+- Framer runs deep repros because the task artifact was thin
+- Observer fixes small issues while inspecting evidence
+- Coder rewrites task meaning in order to declare success
+
+Those are not efficiency wins. They are signs that the lane contract is dissolving.
+
+## Minimum acceptance bar for moving to stage 4
+
+This stage is ready for harness and playground design only when reviewers can answer all of these clearly:
+- which capability classes are required by the lane overall
+- which of those capabilities belong to each role
+- which boundary violations would invalidate the advisor-primary model
+- how the tools model preserves Iterator as the single accountable owner

devin/nodes/iterate/_archived_design_stages/04-harness-and-playground.md

@@ -0,0 +1,32 @@
+# Iterate harness and playground design
+
+## Purpose
+
+The harness should exercise the lane as an orchestration contract, not just as prompt prose.
+
+## Required harness abilities
+
+- inject route context and prior turns
+- inspect authored artifacts at each stage
+- inspect iterate artifacts under `.devflow/iterate/<task_id>/`
+- simulate coder retries and near misses
+- compare terminal claims against observation truth and success criteria
+- verify that readiness state transitions happen before and after coder attempts at the right times
+- verify monotonic revision bumps on top-level artifacts when framing, observation, or supervision state changes
+- inspect `promotion_handoff.json` when work exits to `idea` or `insight`
+- read attempt-scoped verifier artifacts without requiring them to be inlined into `iterator_run.json`
+- assert deterministic attempt ordering via ordinal ids like `attempt-001`
+- parse a shared verifier-artifact envelope before descending into verifier-specific payloads
+
+## Minimum fixture families
+
+- reproducible error fix
+- targeted improvement with a bounded failing seam
+- ambiguous request needing framing discipline
+- non-confirmed issue requiring honest blockage
+- broader request that must promote to `idea`
+- read-only request that must route to `insight`
+
+## Success condition
+
+The harness is good when it can catch false-positive completions, scope drift, missing-artifact shortcuts, incorrect iterator state transitions, missing promotion linkage, broken artifact revision discipline, non-monotonic attempt ids, and verifier outputs that skip the shared normalization envelope.

devin/nodes/iterate/_archived_design_stages/05-prompt-deferred.md

@@ -0,0 +1,11 @@
+# Prompt deferred
+
+Prompt authoring for the iterate lane is intentionally deferred.
+
+Prompt work should start only after:
+1. objectives and requirements are accepted
+2. evals are accepted
+3. tools and boundaries are accepted
+4. harness and playground expectations are accepted
+
+Until then, prompt placeholders are acceptable, but real prompt content is out of scope for this directory pass.

devin/nodes/iterate/_archived_design_stages/coder_agent_design/01-objectives-requirements.md

@@ -0,0 +1,20 @@
+# Coder, objectives and requirements
+
+## Objective
+
+Implement the scoped delta described by the task and observation artifacts, then report the attempt honestly.
+
+## Requirements
+
+- stay inside the scoped task unless Iterator explicitly broadens it
+- treat framing and observation artifacts as the governing contract
+- implement the smallest change that can satisfy the green condition
+- run the narrowest valid verification seam
+- report what changed, what passed, what failed, and what remains blocked
+- support repair-specific retries when Iterator respawns with tighter context
+
+## Derived non-goals
+
+- do not redefine the task contract
+- do not broaden scope for opportunistic cleanup
+- do not self-certify final completion

devin/nodes/iterate/_archived_design_stages/coder_agent_design/02-evals.md

@@ -0,0 +1,8 @@
+# Coder evals
+
+- fixes a reproducible error without unrelated drift
+- satisfies a targeted improvement seam with a minimal change
+- reports partial progress honestly after a failed first pass
+- stays within the scoped files or surfaces when the task is narrow
+- provides actionable blocker detail when safe completion is impossible
+- improves on a second attempt when respawned with repair context

devin/nodes/iterate/_archived_design_stages/coder_agent_design/03-tools-and-boundaries.md

@@ -0,0 +1,14 @@
+# Coder tools and boundaries
+
+## Needed capabilities
+
+- read task and observation artifacts
+- inspect and modify scoped project files
+- run narrow verification commands or checks
+- write attempt summaries into the iterator run record
+
+## Boundary rules
+
+- should not redefine task scope or user intent
+- should not convert an observation gap into a fake success claim
+- should not claim final victory without Iterator validation

devin/nodes/iterate/_archived_design_stages/coder_agent_design/04-harness-and-playground.md

@@ -0,0 +1,12 @@
+# Coder harness and playground
+
+The harness should inspect:
+- whether the implementation stayed in scope
+- whether the chosen verification seam was narrow and relevant
+- whether the attempt report is honest about passes, failures, and blockers
+- whether repair retries materially improve alignment
+
+Key fixtures:
+- reproducible fix succeeds in one pass
+- first pass fails, second pass succeeds
+- safe completion is impossible and the blocker is reported clearly

devin/nodes/iterate/_archived_design_stages/framer_agent_design/01-objectives-requirements.md

@@ -0,0 +1,20 @@
+# Framer, objectives and requirements
+
+## Objective
+
+Turn the user's messy request and relevant context into a bounded iterate task artifact that another role can safely act on.
+
+## Requirements
+
+- classify the request as error fix, quick change, or targeted improvement
+- extract the most likely surface, route, file, component, or function hints when available
+- distinguish current behavior from desired behavior
+- write observable success criteria
+- separate facts, assumptions, blocking unknowns, and nonblocking unknowns
+- recommend stay iterate, investigate first, or promote to idea
+
+## Derived non-goals
+
+- do not perform observation work
+- do not code
+- do not broaden the task to make it sound more important

devin/nodes/iterate/_archived_design_stages/framer_agent_design/02-evals.md

@@ -0,0 +1,8 @@
+# Framer evals
+
+- turns a messy fix request into a bounded task artifact
+- preserves partial location hints instead of discarding them
+- keeps a tiny request small rather than inflating it
+- marks blocking unknowns honestly when the ask is underspecified
+- distinguishes current behavior and desired behavior clearly
+- recommends promotion when the request is no longer task-scale

devin/nodes/iterate/_archived_design_stages/framer_agent_design/03-tools-and-boundaries.md

@@ -0,0 +1,13 @@
+# Framer tools and boundaries
+
+## Needed capabilities
+
+- read conversation context and project hints
+- inspect lightweight repo clues when necessary to localize the surface
+- write the task artifact
+
+## Boundary rules
+
+- should not collect evidence that belongs in observation truth
+- should not run implementation changes
+- should not hide uncertainty behind overconfident framing prose

devin/nodes/iterate/_archived_design_stages/framer_agent_design/04-harness-and-playground.md

@@ -0,0 +1,12 @@
+# Framer harness and playground
+
+The harness should inspect whether Framer outputs:
+- a coherent task type
+- a clear current versus desired behavior split
+- observable success criteria
+- explicit unknowns and promotion guidance
+
+Key fixtures:
+- messy error report with partial location
+- tiny copy or behavior tweak
+- underspecified but repairable request

devin/nodes/iterate/_archived_design_stages/iterator_agent_design/01-objectives-requirements.md

@@ -0,0 +1,25 @@
+# Iterator, objectives and requirements
+
+## Objective
+
+Own the iterate lane end to end and return one truthful outcome:
+- completed
+- blocked
+- needs more context
+- promote to idea
+- route to insight
+
+## Requirements
+
+- synthesize Framer and Observer artifacts without collapsing their roles
+- decide coding readiness before spawning Coder
+- keep scope aligned to the original task contract
+- issue repair-specific respawns when the first coding pass is close but incomplete
+- refuse premature completion
+- author the final lane verdict and rationale
+
+## Derived non-goals
+
+- do not serve as the primary coding worker
+- do not hand-wave missing observation truth
+- do not bury promotions or blockers inside optimistic language

devin/nodes/iterate/_archived_design_stages/iterator_agent_design/02-evals.md

@@ -0,0 +1,9 @@
+# Iterator evals
+
+- declines to spawn Coder when task artifact is vague
+- declines to spawn Coder when observation artifact is inconclusive for a required repro
+- respawns Coder with a precise repair reason after a near miss
+- refuses completion when the green condition is still red
+- refuses completion when success criteria are only partially satisfied
+- promotes to `idea` when scope expansion becomes necessary
+- returns a blocked verdict when safe progress depends on missing evidence

devin/nodes/iterate/_archived_design_stages/iterator_agent_design/03-tools-and-boundaries.md

@@ -0,0 +1,14 @@
+# Iterator tools and boundaries
+
+## Needed capabilities
+
+- read framing, observation, and attempt artifacts
+- supervise worker attempts
+- run or request final narrow verification checks
+- write final disposition and respawn rationale
+
+## Boundary rules
+
+- may coordinate all agents, but should not absorb coding as the default path
+- may inspect verification evidence, but should not invent it
+- may revise task handling, but should not casually overwrite Framer or Observer truth without explanation