Seedless mode should support persistent project scaffolds separate from repeated prompt instructions

[KE7]

Summary

Seedless mode currently starts from an empty worktree and relies on the seed-generation prompt to explain all required project structure. This works, but it makes users repeat stable structural requirements in agent.background, because later mutation prompts also need to preserve the generated entry points and file layout.

It would be useful for HELIX to support a small persistent seed scaffold/template that is copied into the seedless worktree before the first generation, while still treating the actual solution as seedless.

Motivation

Many software optimization tasks have a stable harness contract, for example:

• a required package/module path
• a required function or CLI entry point
• a config file that should remain present
• test/evaluator files that should remain protected

These are not really candidate solution content. They are interface contract and project shape. Without a scaffold mechanism, users have to encode that structure in the seed prompt and often keep repeating it in mutation prompts to prevent later generations from deleting or renaming the required entry point.

That wastes tokens and makes prompt wording do work that a file-level scaffold could do more reliably.

Proposed behavior

Add a seedless option such as:

[seedless]
enabled = true
scaffold_path = "seed_scaffold"

or:

[seedless.scaffold]
paths = ["src/", "README.md"]

When seedless mode creates the empty seed worktree, HELIX would copy the scaffold into the worktree before invoking the seed-generation mutator.

The seed-generation prompt can then stay short:

• optimize the objective
• preserve the existing public entry point
• use the included docs/tests

Subsequent mutation prompts can rely on the scaffold files being part of the candidate history, instead of re-describing the structure every generation.

Desired properties

• Scaffold files are copied before the first seed-generation call.
• The scaffold can include mutable and protected files, governed by existing protected_files / sandbox omission rules.
• This should not require an initial validation run of a non-solution seed.
• This should still count as seedless from the optimization perspective: no hand-written implementation is being evaluated as the initial candidate.
• The feature should work for pure software tasks generally.

Alternatives

1. Put all structure instructions in agent.background.

   • Simple, but repeated every generation and easy for the agent to ignore or drift from.

2. Start non-seedless with a minimal stub candidate.

   • Works, but the stub is evaluated as a real candidate, which is conceptually awkward when the user wants the first meaningful implementation to be generated by the agent.

3. Teach the evaluator to create missing files.

   • Keeps prompts shorter, but mixes project scaffolding with evaluation and can obscure what the candidate actually produced.

Open question

Should scaffold files be committed into the seed candidate before generation, or copied as uncommitted files for the seed-generation agent to modify and then committed by the normal HELIX snapshot flow?