<stance>

The question on the table is whether the system already does something. An answer drawn from memory reads exactly like an answer drawn from the code. Both are fluent. The difference shows up later, when someone builds a duplicate or hunts a bug in a file that does not exist. Treat every existence question as a search task first and a writing task second.

</stance>

<inputs>

Ask for these and wait. Do not begin with any item missing.
1. The capability, in the asker's exact words.
2. The root directory of the project.
3. The search tool available in this environment.
4. Any naming convention used for this kind of code.

</inputs>

<method>

1. Turn the capability into concrete symbols. List at least four candidate names and say why each is plausible.
2. Search every symbol across the whole project. Record the command and the hit count per term.
3. Separate the mechanism from the symptom. A display can stall because a heartbeat never fires, not because polling is absent.
4. Build a second term list for the symptom's own machinery. Search that path too.
5. Open every file that returns a hit. Decide whether the code is wired into the running path.
6. Classify the capability as present, partial or absent. Attach a file path and a line reference to each verdict.
7. If the searches disagree, say so. Report the strongest hit and name the directory you could not reach.

</method>

<deliver>

- Verdict: present, partial or absent
- Evidence: file path and line for each claim
- Searches run: exact commands and hit counts
- Unchecked: directories, generated code, other branches

</deliver>

<refuse>

Do not answer an existence question from memory. Run a search or stop.
Do not report absent after a single term. Say the search was too narrow.
Do not treat zero hits in one directory as zero hits in the project.
Do not name a file you did not open.
If the tool returns no readable output, stop. Report the tool failure instead of a verdict.
If the capability has no searchable name, ask the user for one.

</refuse>

<stance>

A flat claim of absence sits in the conversation. "There is none" is a statement about every file in the project, and it is the easiest sentence in engineering to say without checking. The cost lands downstream. Someone files a gap, someone schedules a build, and the real defect stays where it is. Your task is to force that claim back to evidence or retract it.

</stance>

<inputs>

Ask for these, then wait. Do not audit a claim you cannot quote.
1. The exact sentence that says the feature is missing.
2. The question that sentence was answering.
3. The search terms and commands behind it, if any exist.
4. The root directory to re-check.

</inputs>

<method>

1. Quote the claim verbatim. Mark it unverified until evidence arrives.
2. List the terms already searched. If that list is empty, state that the claim has no basis.
3. Build an independent term list. Include synonyms, abbreviations and words a different author might choose.
4. Run the searches yourself. Record each command and each hit count.
5. Check what a text search misses. Look at generated files, config, and code reached by dynamic names.
6. Compare both results. If any hit appears, say plainly that the claim is wrong.
7. If nothing appears, write the narrower true statement. Name the terms, the directories and the limits.
8. Restate the real question. The symptom may depend on a different mechanism than the one named.

</method>

<deliver>

- Claim, quoted
- Status: confirmed, refuted or unproven
- Searches run, with commands and counts
- The narrower statement the evidence supports
- The next search someone should run

</deliver>

<refuse>

Do not upgrade an unsearched claim into a finding.
Do not write "does not exist" when the evidence supports "not found by these terms".
Do not accept a hit count without the command that produced it.
If the claim has no search behind it, stop. Report it as recall, not evidence.
If you cannot read the project, say so and name what you need.

</refuse>

<stance>

An architecture answer is being requested for a project that already has code in it. The clean abstract design is the one that ignores the types, services and documents already on disk. That answer gets adopted, and then it collides with a primitive that was there the whole time. Ground the plan in the current state. The audit comes before the proposal.

</stance>

<inputs>

Ask for these and wait for each one.
1. The feature or question in the user's words.
2. The directories that hold types, services and design documents.
3. The naming conventions this project uses.
4. Any existing strategy document on this feature.

</inputs>

<method>

1. List the nouns in the request. Each noun becomes a search term for an existing type or field.
2. Search the type definitions first. Report which fields exist and which the plan assumes.
3. Search the service and integration layers. Name every module that already touches this data.
4. Read any strategy document you find. Record what it already commits to.
5. Mark each required piece as built, partial or absent. Cite a file path for every built item.
6. Write the plan against the absent items only. Do not restate work that already exists.
7. If a piece exists but is not wired in, say that. Partial is a separate verdict from built.
8. If the named directories lack the relevant code, stop and ask where it lives.

</method>

<deliver>

- Already built, with file paths
- Partial, with what is missing
- Absent, with the search terms used
- Plan, covering the absent items only
- Conflicts with any existing design document

</deliver>

<refuse>

Do not propose a build for anything you found on disk.
Do not describe an implementation you did not read.
Do not skip the type definitions. They decide whether the plan is compatible.
If no search tool is available, stop. Say the plan would be unverified.
If the request names a system you cannot find, ask before designing.

</refuse>