Tell the harness agent not to extend a non-deployable contract - #130
Merged
Conversation
The instruction to write "a minimal contract which simply extends the target" holds only when the target is deployable. Extending an abstract contract -- or one that leaves part of an inherited interface to a sibling that is mixed in further down the hierarchy -- produces a harness solc rejects, and even if it compiled the Prover would have no instance for it. Judging deployability also cannot be done from the target's own file: the unimplemented functions may be declared in an interface it inherits. Direct the agent to harness the concrete contract the protocol deploys in that case, and to fill in the missing functions itself only when the project has no concrete contract inheriting from the target. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This was referenced Aug 7, 2026
Contributor
Author
|
as far as prompting can go... |
jtoman
approved these changes
Aug 11, 2026
shellygr
enabled auto-merge (squash)
August 12, 2026 12:04
ericeil
added a commit
that referenced
this pull request
Aug 14, 2026
…loyable contract) into eric/rust Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The harness generation prompt says the harness should be "a minimal contract which simply extends the target contract", adding "only code necessary to satisfy the Solidity compiler/typechecker". That holds only while the target is deployable.
When the target is
abstract, extending it directly produces a contract solc rejects — and even if it compiled, the Prover would have no instance for it. Judging deployability from the target's own file is not enough either: a function can be declared in an interface the target inherits and implemented by a sibling contract mixed in further down the hierarchy, so the target's file shows no sign it is missing.That is exactly how a dev run failed. The agent harnessed an abstract base, implemented the unimplemented functions it could see in that base's file, and missed five more declared only in an inherited interface. The run died in AutoSetup.
Change
Prompt-only. Directs the agent to treat deployability as a precondition: when the target is abstract (or otherwise leaves an inherited function unimplemented), harness the concrete contract the protocol actually deploys, choosing by the deployment scripts/configuration where several exist. Implementing the missing functions in the harness itself stays available, but as the last option, for a target with no concrete descendant at all.
Validation
Template renders. This is the weakest of the three fixes on its own — it asks the model to get something right rather than making it impossible to get wrong — so it is worth landing behind the compile gate, which turns a wrong choice into a repair loop instead of a dead run.
Follow-up worth considering
Whether a target is abstract is a fact we can compute rather than ask for: a parse-only
solc --standard-json(stopAfter: "parsing") yieldsContractDefinition.abstractin milliseconds with no dependency resolution. Passing that per target into the prompt — or, better, resolving abstract components to their concrete descendants upstream in the component analysis, wherenum_instancesis assigned to a contract that can never be a Prover instance — would remove the judgment call entirely. Left out here to keep this a prompt change.Companions
Two independent PRs address the same failure: the harness compile gate, and a terminal AutoSetup detection for the resulting compiler error.
Companion PRs: #129 #131. They are independent — any order, any subset.