Skip to content

#1071 and #1107 are merged into santos/dev2 by ancestry, and their surface work is not in the tree #1368

Open

Description

@santoshkumarradha

Bringing dev into santos/dev2 merges #1071 and #1107 by ancestry while
deliberately NOT bringing their surface work into the tree. This issue is the
record of what was left out, and the work to bring it across properly.

READ THE ANCESTRY CAREFULLY. After that merge, git log will show both commits
reachable from santos/dev2. Their changes to the twelve files below are not in
it. Ancestry and content disagree on purpose, and this issue exists so that
disagreement is written down somewhere a person will find it.

Why they were left out

The merge brought six commits across a three day gap. Fifty six files
conflicted. Most of them were the same work arriving twice by two routes, and
those were settled by proof rather than by preference: for each file, whether
dev's exact blob is a state santos/dev2 already passed through. Twenty six
answered yes.

The twelve below did not. They are the ones #1071 and #1107 touch, and on each
of them the two sides are two people's intent three days apart rather than an
old copy and a new one. Resolving them either way is a behaviour change to the
surface, and a behaviour change inside a fifty six file merge is one nobody
reads as a behaviour change.

THE GATE CANNOT SEE THESE. The untagged words check asserts a needle exists
somewhere in internal/tui3. It cannot see whether the screen spells two of
them adjacently, or files a row under a heading, or draws a key on a row. Only
the tagged terminal suite notices that kind of rot, and it is in no workflow
(#1361). So the usual answer, resolve it and let the gate decide, is not
available here.

The files

internal/tui3/homepanel_needs.go, internal/tui3/pages.go,
internal/tui3/palette.go, internal/tui3/tasksplace.go,
internal/tui3/lanes_test.go, internal/tui3/palette_test.go,
internal/e2e/tui_e2e_test.go, internal/e2e/tuiwords_test.go,
internal/manual/chat/commands.md, internal/manual/chat/how-tasks-run.md,
internal/manual/chat/models-and-cost.md, internal/manual/chat/tasks.md.

Twenty six conflicting hunks across them.

The decision that has to be made by a person

DOES A NEEDS ROW NAME THE DOOR IT TAKES. The two sides are not a mistake and a
fix. They are two intents, and each left a comment explaining itself.

santos/dev2 keeps the branch and REFINES it. An item stopped on a permission
also gets the standing word, because nobody wrote that line, the conversation
holds nothing to answer, and what a person can do about it lives on the item's
own page:

cell.subRight = needsOpenWord
if standing.IsPermissionLine(row.item.Item.NeedsPerson) ||
    strings.TrimSpace(row.item.Item.Origin.Transcript) == "" {
    cell.subRight = needsStandingWord
}

#1071 DELETES the branch, and says the row names neither door, pointing at
needsAnswersCap for the rule. needsOpenWord and needsStandingWord do not
exist anywhere on dev; on santos/dev2 they are used by
homepanel_needs.go and two tests.

Two more of the same shape, given as sizes because the content is long:
pages.go's first conflict is nine lines at the merge base, grown to
thirty three on santos/dev2 and deleted outright by #1071. palette.go's
seventh is a hundred and thirty at the base, eighty three on santos/dev2,
fourteen on dev.

What bringing them across should look like

One reviewed change per commit rather than one lump, each saying which intent
won on every disputed line and why.

ACCEPTANCE IS THE TAGGED SUITE, because nothing else can see this work. A run
against a real model, with the subtest list, diffed against the last known
zero failure baseline. A green build, a green words check and a green touched
packages run prove nothing here and should not be offered as if they did.

The needs row question above is a product decision with an author and wants an
answer before the reconciliation starts, not during it.


Drafted with CodeAF · reviewed and owned by the author

Activity

  1. santoshkumarradha commented on Sep 22, 2026

    @santoshkumarradha
    MemberAuthor

    The merge this issue was opened for WAS NOT PUSHED, and the reason is the more
    useful half of the work.

    A textual conflict count is not a measure of a change's reach

    #1071 touches 406 files. #1107 touches 46. 425 unique. Twelve of them
    conflicted.
    The other 413 merged cleanly and carried dev's content.

    The plan this issue described, resolve the twelve to santos/dev2 and call the
    merge behaviour preserving, was therefore wrong by a factor of thirty five. The
    twelve were never the surface change. They are only where two lines of
    development happened to collide TEXTUALLY, which is a fact about how the two
    files were edited and not about what the commits do.

    The resulting tree had dev's surface in 413 files and santos/dev2's in
    twelve, and it does not build:

    pages.go      the place interface declares window, box and caretRow twice
                  (209/242, 211/272, 235/262) and placeBase.caretRow at 373 and 381
    palette.go    laneTerm undefined at 447, 529, 543, 556, 589
    app.go:4247   taskSheetHover used as a value: one side returns tea.Cmd, the
                  other returns nothing, and the caller came from the side that lost
    settings_test.go:1525  HeadlessToolApprovalModeAt undefined
    

    Two test failures are the same seam rather than separate news: the tagged-suite
    words table wants homeFootWord, which is dev's foot, and the surface-door
    ledger says workingNowAgent now crosses the wire. Change entries, gofmt and
    the laws were green throughout, which is the point: none of those can see this.

    GENERALLY. Before resolving conflicts in a catch-up merge, measure what the
    incoming commits TOUCH, not what they collide with. The two numbers can differ
    by an order of magnitude, and every conclusion about whether a resolution is
    behaviour preserving depends on the first one.

    And the scope grew

    Taking dev's side on the twelve makes the tree coherent. It also lands two
    things that belong in a reviewed change rather than in a catch-up merge, both
    claimed by #1071's own change entry: remote protocol 17 replacing 16, and
    interactive conversations defaulting to YOLO. santos/dev2 is the line the
    owner's binary is built from.

    So this issue now carries two questions for a person, not one:

    1. Does a needs row name the door it takes, as originally written above.
    2. Are interactive YOLO and protocol 17 meant to reach santos/dev2 by this
      merge, or by a reviewed change of their own.

    What is already established and should not be paid for twice

    The merge commit and a MERGE-NOTES.md beside it record, on an unpushed
    branch: the four acceptance results, including that every commit reachable from
    dev is an ancestor and that bbdd7cd (#1282) survives with its behaviour at
    internal/exec/bare/tools.go:551 and :577; the twenty six conflicts resolved
    by PROOF rather than preference, each naming the santos/dev2 commit at which
    dev's exact blob was that branch's state; and the four resolutions that were
    a union or a proven superset rather than a side. None of the twenty six is in
    the 425-file surface set, so that half stands whichever way the two questions
    above are answered.

  2. added
    hygieneTests, laws, dead code, duplication — no person-facing change
    on Sep 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:chatThe v3 surface a person sits in front of (internal/tui3)hygieneTests, laws, dead code, duplication — no person-facing change

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions