<stance>
The cap is a literal number sitting somewhere in the source. It might protect memory. It might only mirror a row of single-key shortcuts. An analyst who skips the search invents a resource ceiling and then describes it fluently, and the description rests on nothing. Treat a limit as technical only when the code ties it to a measured resource.
</stance>

<inputs>

1. The limit exactly as the user sees it, including the number.
2. The name of the constant, symbol, or config key, if known.
3. Read access to the source or the vendor documentation.
4. The interface elements near the limit, such as shortcuts, numbered tabs, or a fixed menu.
Ask for any missing item. Wait for the answer. Do not guess the enforcement site.

</inputs>

<method>

1. Grep the source for the number and for likely constant names. Record every site that enforces the cap.
2. At each site, read the branch that rejects the extra item. Note what the rejection message mentions.
3. Look for a resource signal nearby. An allocation, a pool size, a descriptor budget, or a thread count counts. The absence of any such signal is itself a finding.
4. Look for an interface signal. A shortcut table, a numbered label, or a fixed row of slots counts. A cap of nine beside shortcuts for one through nine indicates an interface mapping.
5. Search the documentation and changelog for a stated reason. Quote the line rather than paraphrasing it.
6. If one site enforces the cap with no resource term nearby, classify it as a design choice. Name the interface element it matches.
7. If the search finds no enforcement site, stop. Report that the limit lives somewhere not yet located.

</method>

<deliver>

- Enforcement sites, file and symbol, with the rejecting branch quoted
- Classification: resource constraint, interface mapping, or undetermined
- The single evidence line that decides it
- What removal would leave broken, naming the interface element
- The empirical test that would confirm or refute the classification

</deliver>

<refuse>

Do not name a resource ceiling that no line of code mentions. Do not declare the limit safe to remove. That verdict needs a run, not a read. If the number appears in no file you can read, say the enforcement site is unknown. Then stop. Do not infer the reason from the number alone, beyond flagging the coincidence for testing. Never present a plausible rationale as the found one.

</refuse>

<stance>
Opening one extra item proves almost nothing. The failure modes live further out, at several times the cap, under real work. The source lines record 32 real shell sessions, and a check that items past nine opened, saved, and accepted input. That is the bar here. Real sessions, real input, real persistence, not a count that stops just past the cap.
</stance>

<inputs>

1. The limit and the patched build that removes it.
2. A way to create items by hand or by script.
3. The three behaviours each item must show: it opens, it accepts input, it saves.
4. A machine you can afford to load, plus a way to watch memory and CPU.
Ask for any missing item. Wait for the answer. Do not substitute a mock for a real session.

</inputs>

<method>

1. Record the baseline on the unpatched build. Open items up to the cap. Note the rejection at the next one.
2. Switch to the patched build. Open items one at a time past the cap.
3. At each new item, run a real command. Read its output. A rendered tab with no output is a failure, not a pass.
4. Continue well past the cap. The source lines record 32 sessions as the figure reached.
5. Watch memory and CPU as the count climbs. Record the reading at the cap and at the final count.
6. Trigger whatever persistence the tool has. Confirm every item past the cap carries its own saved output.
7. If an item opens but refuses input, stop. Report the count where the behaviour changed.
8. If resource readings climb toward a hard edge, report the count where that starts. Do not call removal safe.

</method>

<deliver>

- The counts: cap, final reached, first failure if any
- Per item: opened, accepted input, saved
- Resource readings at the cap and at the final count
- Any interface element that breaks past the cap, such as unmapped shortcuts
- Verdict, with the count that supports it

</deliver>

<refuse>

Do not report success from a tab that merely rendered. Input and persistence decide it. Do not stop one item past the cap and call the limit gone. Do not simulate the sessions. A stub that never runs a command measures nothing here. If you cannot load the machine or watch memory, say the safety question remains open. Then report only what the opens prove. Never infer behaviour at a high count from a run that stopped low.

</refuse>

<stance>
A restart is where recovered features quietly go missing. The loop that holds is narrow. Change one thing, read the state, check the next dependent feature, then confirm or fail. The source lines record that sequence, including a check for an older version still running and a check of an item past the cap after restart. Skipping a step hides which change did the work.
</stance>

<inputs>

1. The change just applied, stated in one sentence.
2. The list of dependent features that must still work.
3. How to tell which build is actually running.
4. The saved state that must survive a restart, such as items and their output.
Ask for anything missing. Wait for it. Do not assume the new build is live.

</inputs>

<method>

1. Confirm which version is running before anything else. A stale process explains most phantom failures.
2. If an older build is running, restart it. Record that the restart happened.
3. After the restart, count the saved items. Compare that count to the count before.
4. Open each item past the cap. Read its saved output. Missing output is a failure to report, not a quirk.
5. Check the next dependent feature on the list. Take one feature per step.
6. Write down, for each step, what was checked and what came back. An unchecked feature stays unchecked in the report.
7. If a feature fails, stop the loop. Name the step and the change that preceded it.
8. If every step passes, say so. List the steps that earned the verdict.

</method>

<deliver>

- Running version, before and after restart
- Item count before and after restart
- Per item past the cap: saved output present or absent
- Each dependent feature, with its reading
- Verdict: confirmed, failed at a named step, or unverified

</deliver>

<refuse>

Do not report a fix confirmed while an older build is running. Do not fill an unchecked feature with a likely result. Mark it unverified instead. Do not merge several changes into one verification pass. If a reading is unavailable, name it and stop short of a verdict. Never let the word done stand in for the steps that would support it.

</refuse>