No "search" verb in the baseline lexicon

[gitosaurus]

search <object> answers "I can't find a verb in that sentence." in Starship and in anything else built on games/lexicon.arch. It is a word players reach for constantly, and reaching for it gets them a parser error rather than a refusal — the worst kind of answer, because it reads as "that idea is wrong" instead of "that word is wrong".

This came up while fixing "x pants" doesn't indicate pockets (#49). That change made examining the pants report the pockets, so the immediate unfairness is gone, but search pants still fails outright while look in pants works.

The obstacle is that there is no single obvious meaning to give it:

• Gorreven already defines one (games/gorreven_lex.arch:34) and it means get closer: a hollow_object is entered, a live guard refuses, and anything whose 'look' comes back ABSENT gets "I find nothing unusual even upon a close search." It is also syn : 'examine' there, so in Gorreven "search" and "x" are the same verb.
• The natural Starship meaning is different — for the pants, "search" means 'look in', the thing that turns the pockets out.

So a baseline 'search' would have to pick one, and either choice makes the other game's version the odd one out. Options, roughly in order of how much they commit to:

1. Add Verb null full : 'search' to games/lexicon.arch with a normal of something like "I'd have to be more specific about where to look." — costs nothing, stops the parser error, and leaves each game free to define 'search' where it means something.
2. The above, plus 'search' : 'look in' on the object class in games/intrptr.arch, making the baseline meaning "look inside this".
3. Leave it to each game, and just accept that Gorreven has it and Starship does not.

Option 1 is the cheap one and does not foreclose the others. Option 2 is the one that would have made search pants do the right thing without anyone thinking about it.

Worth noting either way: whatever the baseline does, Gorreven's 'search' should probably keep meaning what it means today, since its syn : 'examine' makes it load-bearing for that game's prose.

[gitosaurus]

Survey: what "search" means, and where it belongs

The semantic frame. There are three rungs and interactive fiction only ever built two:

• look — what is here?
• look at / x / examine — what is this thing showing me?
• search — what is this thing withholding?

Examine takes what an object offers. Search takes what it keeps back. Examining doesn't change the world; searching usually does — it opens, it spills, it moves you closer.

The instinct that "examine" sits nearer to "search" is right about English and wrong about the convention: Infocom flattened examine onto look because players used them interchangeably, and kept search separate. The interesting part is that this repo already contains a vote on the question. gorreven_lex.arch:36 puts syn : 'examine' on the search verb. That is the English meaning being chosen over the inherited one.

It never took effect. lexicon.arch:5 claims 'examine' for 'look' first, and the first claim on a word wins — a later colliding syn is dropped silently. Verified: examine cot and x cot are identical, and only search cot gets closer and reveals the sharp piece of metal. So the caveat at the bottom of this issue, that syn : 'examine' makes Gorreven's search load-bearing, is void. The two verbs have always been separate.

Gorreven already has both candidate meanings, not one.

• Verb level (gorreven_lex.arch:39) — a case over main.subj: hollow object → enter it; live guard → refuse; 'look' came back ABSENT → "I find nothing unusual even upon a close search."
• Object level (gorreven.arch:1442) — filing_cabinet overrides 'search' as: open it if closed, then 'look in'.

That override is the Starship pants meaning, already written, in Gorreven. The two readings this issue treats as irreconcilable already coexist inside one game, and that game reconciles them by dispatching to the object.

So harmonizing means agreeing on the question, not on the answer. search X always asks what is X withholding? Each object answers in its own voice: Gorreven's cot by moving you onto it, Starship's pants by spilling their pockets, a rock by having nothing to say. Genre colour — a spy game's search being more active than a domestic one's — becomes an object or class override rather than a private verb.

Which makes this a relocation rather than an addition:

class	'search' becomes	source
object	'look in'	declines by inheritance — a rock has no 'look in', so it answers ABSENT and the verb's normal speaks
hollow_object	'enter'	Gorreven's verb-level branch, promoted
openable	if not open then 'open', then 'look in'	filing_cabinet's override, promoted
container	'look'	already reports full or empty

lexicon.arch then carries the word and the refusal, nothing more. Gorreven's guard branch becomes a 'search' method on guard_type. filing_cabinet's override deletes itself. Starship's pants need no change at all — they already answer 'look in' at starship.arch:1888.

One hard constraint: this cannot be additive. First-wins applies to full as well as to syn:

Verb null  full : 'frob'  normal : "*** FIRST-FROB (baseline) ***"  end
Verb null  full : 'frob'  normal : "*** SECOND-FROB (game) ***"     end

> frob rock
*** FIRST-FROB (baseline) ***

Both gorreven.arch:9 and starship.arch:13 include the baseline lexicon before the game's own. So adding 'search' to lexicon.arch silently shadows Gorreven's entire search verb — no error, no failing test, and Gorreven is not a golden. Its verb definition has to come out in the same change. Nothing becomes unwinnable if it doesn't (enter cot still reaches the sharp metal), but the prose and the guard's refusal go quiet.

Cost: repin both goldens, since lexicon.arch is inside standard. No C++.

Sequence: two commits — promote the meanings onto the library classes while Gorreven still owns the word, then move the word — so any shift in Gorreven shows up on its own.