gorodskie-bani.ru

Например: [https://gorodskie-bani.ru/city/kurgan/bani/banya-%E2%84%9611-1720](https://gorodskie-bani.ru/city/kurgan/bani/banya-%E2%84%9611-1720)

Work on lost pages

# Objective

Make the output of places in the AI chat manageable and structured: instead of arbitrary text/links, the agent should be able to explicitly reference a place by its internal ID, and the chat interface should replace such a link with a full-fledged place card.

## Problem

Currently, when recommending or mentioning companies/places, the agent replies in a free form: writes the name in text, adds a URL, or formats the link at its discretion. The frontend cannot reliably determine that a specific response fragment corresponds to a specific place record in the database, making it impossible to stably display cards.

## Proposed Contract

Add a special custom tag to the agent response protocol containing **only the identifier of an existing place**. For example:

```text
<place id="PLACE_ID" />
```

The tag name can be chosen in accordance with current project conventions (`place`, `company`, `venue`, etc.), but the format must be unambiguous, machine-parsable, and documented.

Key principle: The LLM provides only the `id`, while all displayed card data (name, address, photo, rating, link, working hours, etc.) is fetched by the client/server from up-to-date application data. Do not pass these fields inside the LLM tag.

## Backend / AI

1. Update the agent's system prompt/instruction with a rule: when recommending, listing, or specifically mentioning a particular place from the catalog available to it, use the custom tag with that place's ID.
2. Ensure that the place ID is available in the agent's context/tools along with the data the model uses to select the place.
3. Prohibit the model from inventing IDs. A tag is allowed only for IDs obtained from search results/catalog/tools.
4. Define a fallback: if a place cannot be reliably matched to an internal ID, the agent writes plain text without the custom tag.
5. Maintain the ability to add explanatory text around the card: e.g., "For a family visit, … would be suitable" + card tag.

## Chat Frontend

1. Recognize the custom tag in the assistant-message and do not output it to the user as raw text.
2. Load/fetch place data using the `id` and render an existing or new compact place card directly inside the message.
3. Support multiple cards in a single response while preserving the order relative to the text.
4. The card must be clickable and lead to the corresponding place page.
5. Do not interpret arbitrary HTML from the model: the parser must support only the explicitly allowed tag/attribute format.
6. If the ID does not exist, the record is deleted, or card loading fails, the message must not break. Use a safe fallback (e.g., hide the invalid tag or show a neutral text placeholder — choose consistent behavior).
7. Account for streaming: raw unfinished tags must not flicker for the user during generation. Parse the component after receiving the complete tag or buffer a potential tag prefix.

## Recommended Render Format

Model response:

```text
If you want a classic city bathhouse, I would consider:

<place id="abc123" />

And if a modern SPA format is more important:

<place id="def456" />
```

In the UI, the user sees the text, the first place card, the next text, and the second place card — without displaying technical markup.

## Acceptance Criteria

- [ ] A unified custom place tag syntax with a mandatory `id` is defined and documented.
- [ ] The agent receives real place IDs and uses the tag when recommending specific places.
- [ ] The agent does not generate a tag for an unknown/unmatched place.
- [ ] The chat correctly converts the tag into the corresponding place card.
- [ ] Multiple cards interleaved with regular Markdown text work correctly in a single message.
- [ ] The technical tag is not visible to the user, including during the streaming process.
- [ ] An invalid/non-existent ID does not break message rendering.
- [ ] The card leads to the correct place page.
- [ ] Regular Markdown and existing links in messages continue to work without regressions.
- [ ] Tests are added for at least: a single tag, multiple tags, invalid ID, malformed tag, streaming/partial tag.

## To Check Separately Before Implementation

It is worth looking at the current Markdown/streaming render pipeline and deciding where it is best to perform the transformation: before the Markdown parser via tokenizer/AST or as an allowed render extension. Do not use unsafe `dangerouslySetInnerHTML` to process the model response.

Add a structured tag with the place ID in the agent's responses and render the place card in the chat based on it.

Place cards in chat via a custom agent tag

# Task

Currently, the AI agent on gorodskie-bani.ru does not always understand which specific company is being discussed when a user writes from a specific bathhouse/company card.

We need to fix the passing of the current page context to the AI chat.

## What to do

- pass the URL of the current page from which the user is writing in the request to the AI agent;
- if possible, pass it as a separate structured context rather than as part of the user text;
- ensure that the address is available to the agent with every dialog message or in a persistent session context;
- test cases where a user writes from a specific company's card and asks a question without explicitly mentioning its name;
- ensure that the agent uses the URL to determine the current company and does not confuse it with other catalog objects.

## Expected result

If a user is on a specific company's page and asks, for example, "how much is admission?" or "do they have a swimming pool?", the agent should understand that the question refers specifically to the company on the current page.

Pass the current page address to the AI agent so it clearly understands which company the user is asking about.

Fix passing of the page address from which the user is writing

Currently we only have the city center and a general search radius for objects, but for example, Moscow and the Moscow region, and the same goes for other regions... Ideally, we need to search for those that are within a specified larger radius, but not included in the smaller radius.&#x20;

Ideally, it would be great to outline the region altogether, of course, but that's already too much.&#x20;

Tasks

Add search radius parameter to cities

Fix passing of the page address from which the user is writing

Place cards in chat via a custom agent tag

Work on lost pages