Skip to content

Six proposals: explain it, picture it, suggest it, preset it - #417

Merged
VeryComplexAndLongName merged 2 commits into
mainfrom
proposals-simpler-for-the-user
Sep 12, 2026
Merged

Six proposals: explain it, picture it, suggest it, preset it#417
VeryComplexAndLongName merged 2 commits into
mainfrom
proposals-simpler-for-the-user

Conversation

@VeryComplexAndLongName

@VeryComplexAndLongName VeryComplexAndLongName commented Sep 12, 2026

Copy link
Copy Markdown
Owner

Six proposals, no implementation. Raised in review on 2026-09-12: the
new capabilities are not described for a user, the screenshots are
stale, the settings keep growing, and the tool could point out the
non-obvious instead of waiting to be asked.

Change What it is
what-shipped-since-0-44 An article for somebody who has the tool and does not know what is new. Every section cites the archived change it came from, so a claim can be checked rather than believed.
two-steps-to-a-run A short path per common goal — the goal, the file, two steps, the object written, and a link into HARNESS.md for the detail. A goal that needs a third step is recorded as a finding, not padded.
every-screenshot-is-taken-by-a-spec Twenty of twenty-six pictures are hand-taken, most from 22 August, against a requirement that has forbidden it since it was written. Captures for the standalone screens, a dated list for the editor-native ones, and a check so it cannot drift again.
a-hint-says-what-can-run-together readChangeReadiness already computes which changes can start alongside each other. This offers it — with the fact it came from and the exact commands — in both hosts and from the terminal.
a-preset-instead-of-twelve-fields Name the intention, get the ordinary JSON those keys already live in. Not a new configuration layer, and the fields stay.
a-doctor-says-what-would-stop-a-run Ask what this machine is missing instead of starting a run and reading the refusal — the same shape the workspace lease got.

Three decisions worth disagreeing with before any of this is
implemented:

  • The suggestion engine has no background process. The readiness
    report is already rebuilt on the events that change it; a timer would
    recompute the same answer and make "off" mean "computed and hidden".
  • It never names one optimal plan. readChangeReadiness is
    deliberately pairwise — "presenting one would choose for the reader
    and hide that a choice existed" — so hints name every maximal set, or
    none with a count.
  • Nothing generates a change. The review asked for "write me a small
    change that runs this optimally". What is proposed is the plan and the
    commands; a generator that writes an OpenSpec change from a guess is
    the one thing this should not do.

Also answered here, by documentation only: custom agents for Gemini and
Codex. Gemini reads .gemini/agents/*.md (and ~/.gemini/agents),
Codex reads .codex/agents/*.toml (and ~/.codex/agents), and neither
documents a flag that selects one for a single non-interactive run —
Gemini uses an @name prompt prefix, Codex names the agent in the
prompt. This repository's customAgent is a flag on an allowlisted
invocation, so there is nothing to bind to; two-steps-to-a-run records
that in HARNESS.md with the date it was read, and no code changes.

openspec validate --strict --changes: 7 passed, 0 failed. No source
changes, so no changeset.

🤖 Generated with Claude Code

@VeryComplexAndLongName @claude
Six proposals: explain it, picture it, suggest it, preset it
653f297 
Raised in review on 2026-09-12: the new capabilities are not described
for a user, the screenshots are stale, the settings keep growing, and
the tool could point out the non-obvious instead of waiting to be asked.

- what-shipped-since-0-44: an article for a person who has the tool and
  does not know what is new, cited per section from the archived change
  it came from.
- two-steps-to-a-run: a short path per common goal, refused rather than
  padded when it needs a third step. Records what Gemini's and Codex's
  CLIs actually accept for custom agents, and why neither can be given
  one here.
- every-screenshot-is-taken-by-a-spec: twenty of twenty-six pictures are
  hand-taken against a requirement that has forbidden it since it was
  written. Captures for the standalone ones, an explicit dated list for
  the editor-native ones, and a check so the list cannot drift again.
- a-hint-says-what-can-run-together: readiness already computes which
  changes can be started alongside each other; this offers it, with the
  fact it came from and the exact commands. No daemon, no writing, no
  chosen grouping.
- a-preset-instead-of-twelve-fields: name the intention, get the ordinary
  JSON those keys live in. Not a configuration layer.
- a-doctor-says-what-would-stop-a-run: ask what is missing instead of
  starting a run to be refused, with the preflight's own answer for a
  named change.

openspec validate --strict --changes: 7 passed, 0 failed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@VeryComplexAndLongName VeryComplexAndLongName mentioned this pull request Sep 12, 2026
Merged
@VeryComplexAndLongName @claude
Withdraw the presets proposal, and correct the doctor's detection
17aedb2 
Both corrections come from reading the code while implementing the first
of these changes, which is where they should have come from before they
were proposed.

`a-preset-instead-of-twelve-fields` is withdrawn. It proposed named sets
of configuration values with a scope, applied into the ordinary JSON —
which is `HARNESS_TEMPLATES` in `packages/core/src/harness-templates.ts`,
shipped by `presets-by-effort`, offered in the Harness Settings view, and
carrying measured ceilings this repository's own audit log produced. The
proposal described existing behaviour as new. The one axis those four do
not cover is supervision: all of them set `semi-autonomous` with a
human-required gate, and none touches `checkpoints`. Whether that wants a
second axis of named configurations, or nothing, is left open rather than
answered by a change written without noticing the first one.

`a-doctor-says-what-would-stop-a-run` said an agent's binary must be
resolved and never executed. `detectAvailableAgentsDetailed`
(`packages/core/src/agent-detection.ts`) already answers that question by
probing `--version`, and the REST route, the VS Code bridge and the agent
picker all read it. A command answering "is this agent here" differently
from the picker in the same build is exactly the drift the same proposal
objects to one decision further down. It now asks the detection that
exists; if the probe is the wrong mechanism, that is a change to
`agent-detection.ts` and every surface reading it.

`two-steps-to-a-run` no longer points at the withdrawn change; it points
at the named configurations that exist.

openspec validate --strict --changes: 6 passed, 0 failed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@VeryComplexAndLongName VeryComplexAndLongName mentioned this pull request Sep 12, 2026
Merged
@VeryComplexAndLongName
VeryComplexAndLongName merged commit 1c76f72 into main Sep 12, 2026
9 checks passed
@VeryComplexAndLongName VeryComplexAndLongName mentioned this pull request Sep 12, 2026
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@VeryComplexAndLongName