Researching Gourmet Venues (Deprecated Reference)
This rarely used workflow is excluded from active discovery but retained for explicit local compatibility. Keep evidence, scores, and decisions traceable across a six-file city research pack.
Initialize
- Resolve city and output language. Ask once only when language is unspecified, then record it in
overview.md.
- Copy
assets/templates/ into gourmet/<city-slug>/ to create overview.md, inbox.md, candidates.md, notes.md, top-places.md, and excluded.md; replace placeholders before research.
- Preserve original-language venue names unless the user requests translation.
Never fabricate sources, ratings, hours, or claims. Use unknown. Never delete a candidate: mark it rejected and record the reason in excluded.md.
Research and Score
- Capture raw discoveries in
inbox.md, then move viable entries to candidates.md with status.
- Build a
notes.md evidence block for each candidate with practical constraints. Require four independent source roles by default: official channel, maps/aggregator, local reviews, and guide/editorial.
- In an information-sparse locale, use three sources only after recording
evidence: limited, why, and attempted sources. Do not score or publish a recommendation with fewer sources outside this exception.
- When repeated service complaints, hygiene/safety concerns, tourist-trap claims, extreme queues, inconsistent ratings, or unclear access appear, add a focused negative-review section and reflect it in scoring.
- Score and justify each component: Taste/Quality, Value, Convenience, Consistency, and Risk (0–10 each; higher Risk score means lower practical risk).
- Classify totals: Top Pick ≥35, Backup 30–34, Reject <30 or a hard safety/tourist-trap exclusion.
- Synchronize status and score across
notes.md, candidates.md, top-places.md, and excluded.md. Leave no unresolved inbox status in the final pack.
Ranking Retrieval
Before returning “highest score” or top-N results, confirm:
- exact geographic boundary, including suburbs, islands, or neighboring regions
- overall versus cuisine/category scope
- source URL/page title and any area identifier
Handle consent, language, or location gates so list items actually render. If static extraction fails, use available browser tooling; do not substitute a nearby ranking scope. Record exclusions needed to enforce the requested boundary.
Verification
Check all six files exist; language and original-name policy are recorded; claims and ratings have sources or unknown; limited evidence and negative-review triggers are documented; score arithmetic and thresholds are correct; and every candidate appears consistently in recommendation or exclusion outputs.
Return the requested recommendations first, then source coverage, score rationale, practical caveats, and any unresolved evidence gap.
1---2name: researching-gourmet-venues3description: Deprecated internal workflow for auditable city-based food research with multi-source evidence, scope-checked rankings, standardized scoring, and synchronized candidate, recommendation, and exclusion files.4---5
6# Researching Gourmet Venues (Deprecated Reference)
7
8This rarely used workflow is excluded from active discovery but retained for explicit local compatibility. Keep evidence, scores, and decisions traceable across a six-file city research pack.
9
10## Initialize
11
121. Resolve city and output language. Ask once only when language is unspecified, then record it in `overview.md`.
132. Copy `assets/templates/` into `gourmet/<city-slug>/` to create `overview.md`, `inbox.md`, `candidates.md`, `notes.md`, `top-places.md`, and `excluded.md`; replace placeholders before research.
143. Preserve original-language venue names unless the user requests translation.
15
16Never fabricate sources, ratings, hours, or claims. Use `unknown`. Never delete a candidate: mark it `rejected` and record the reason in `excluded.md`.
17
18## Research and Score
19
201. Capture raw discoveries in `inbox.md`, then move viable entries to `candidates.md` with status.
212. Build a `notes.md` evidence block for each candidate with practical constraints. Require four independent source roles by default: official channel, maps/aggregator, local reviews, and guide/editorial.
223. In an information-sparse locale, use three sources only after recording `evidence: limited`, why, and attempted sources. Do not score or publish a recommendation with fewer sources outside this exception.
234. When repeated service complaints, hygiene/safety concerns, tourist-trap claims, extreme queues, inconsistent ratings, or unclear access appear, add a focused negative-review section and reflect it in scoring.
245. Score and justify each component: Taste/Quality, Value, Convenience, Consistency, and Risk (0–10 each; higher Risk score means lower practical risk).
256. Classify totals: Top Pick ≥35, Backup 30–34, Reject <30 or a hard safety/tourist-trap exclusion.
267. Synchronize status and score across `notes.md`, `candidates.md`, `top-places.md`, and `excluded.md`. Leave no unresolved `inbox` status in the final pack.
27
28## Ranking Retrieval
29
30Before returning “highest score” or top-N results, confirm:
31
32- exact geographic boundary, including suburbs, islands, or neighboring regions
33- overall versus cuisine/category scope
34- source URL/page title and any area identifier
35
36Handle consent, language, or location gates so list items actually render. If static extraction fails, use available browser tooling; do not substitute a nearby ranking scope. Record exclusions needed to enforce the requested boundary.
37
38## Verification
39
40Check all six files exist; language and original-name policy are recorded; claims and ratings have sources or `unknown`; limited evidence and negative-review triggers are documented; score arithmetic and thresholds are correct; and every candidate appears consistently in recommendation or exclusion outputs.
41
42Return the requested recommendations first, then source coverage, score rationale, practical caveats, and any unresolved evidence gap.
narumiruna