[kilfor.ru](https://kilfor.ru/) is an active website and internal system of the Kilfor business center.

The project runs on MODX. This version of the system has been in use on-site since 2016; its foundation was previously developed in 2009 for the business center at 21 Novy Arbat.

The project encompasses a public website, a user account dashboard, and application logic related to pass requests, vehicle entry, utilities, and other internal business center processes.

MODX remains the backend of the active system. The public part of the project is being developed separately on a new frontend.

The general state, history, and development of the project are documented in the [main concept](https://fi1osof.ru/concepts/kilfor-modernizatsiya-legacy-modx-proekta).

Kilfor.ru is an active website and internal system of the Kilfor business center. The public-facing part runs on MODX, while the backend maintains the application logic for the user account, pass requests, vehicle entry, utilities (housing and communal services), and other internal processes. Main project concept: https://fi1osof.ru/concepts/kilfor-modernizatsiya-legacy-modx-proekta

Kilfor.ru

Conduct an audit of the current [kilfor.ru](https://kilfor.ru/):

- resource and public page structure;
- templates, chunks, snippets, and frontend dependencies;
- data used and methods of retrieving it;
- forms and public interaction points with the backend;
- login and transitions to the personal account;
- current URLs, redirects, metadata, and indexed pages;
- images, documents, and other public materials;
- outdated data and traces of the previous owner/name;
- external integrations and counters.

The result is needed as an actual map of the public layer before creating the new frontend. Do not rewrite the internal MODX business logic as part of this task.

Document the current state of the public part of the website and dependencies on MODX.

Conduct a technical and content audit of the current kilfor.ru

Based on the audit and actual needs of the business center, determine the structure of the new public website.

Take into account at least:

- the main page;
- presentation of the business center and its advantages;
- buildings/structures and premises;
- infrastructure;
- lease and available premises;
- contacts and inquiry routes;
- login for current tenants;
- necessary documents and official information.

The structure should be based on real user scenarios rather than repeating the old MODX tree.

Form a new information architecture for the public part of the website.

Design the structure and user scenarios of the new Kilfor public website

Создать новый frontend для [kilfor.ru](https://kilfor.ru/) на haih-agent.

Frontend должен быть независим от старых MODX-шаблонов и поддерживать новую структуру сайта, адаптивный интерфейс, современные компоненты и дальнейшее развитие публичной части без необходимости переделывать legacy frontend MODX.

MODX сохраняется как backend действующей системы.

Создать новый публичный frontend сайта на haih-agent.

Разработать новый frontend kilfor.ru на haih-agent

Determine what data and actions the new public frontend should receive from the existing MODX, and implement the necessary integration layer.

Do not transfer internal business logic to the frontend and do not rewrite the backend without a separate necessity.

Pay special attention to ensuring that the existing user account, passes, vehicle entry, utilities, and other internal processes continue to work without changes for users.

Define and implement a secure interaction layer between the new frontend and MODX data and functions.

Organize integration of the new frontend with the existing MODX backend

Redesign the commercial presentation of spaces on the new website.

It is necessary to determine what data is actually available and should be displayed: buildings, areas, purpose, condition, photographs, rates, availability, and other characteristics.

Develop a convenient user journey from getting acquainted with the property to applying for a specific space. Separately, figure out the role of the existing kilfor-arenda.ru and what functions/data should remain there or move to the main public contour.

Make public information about leasing clear and useful to a potential tenant.

Redesign the presentation of lease and available spaces

Reorganize public contact and inquiry points.

Separate scenarios at least for:

- potential tenants;
- current tenants;
- visitors who need to contact administration;
- users transitioning to internal services.

The new frontend must feature clear actions and contacts without the need to search for them across old pages.

Make communication and inquiry methods clear for different types of visitors.

Revamp contacts and inquiry scenarios from the public website

When creating a new frontend, preserve useful existing URLs or set up correct permanent redirects.

Check and clean up:

- title and description;
- heading structure;
- canonical;
- robots and sitemap;
- structured data where appropriate;
- page indexability;
- images and alt attributes;
- internal linking;
- pages associated with the old entity name.

Do not migrate outdated content just to preserve the old structure.

Prepare the migration of the public-facing part without losing accumulated search signals.

Preserve and improve SEO when migrating to a new frontend

Проверить новый frontend по базовым эксплуатационным параметрам:

- мобильная адаптация;
- скорость загрузки и Core Web Vitals;
- размеры и форматы изображений;
- корректная работа навигации и интерактивных элементов;
- доступность основных сценариев с клавиатуры и для assistive technologies;
- стабильность на актуальных браузерах и устройствах.

Особое внимание уделить страницам с большим количеством фотографий и объектов.

Обеспечить современное качество публичного frontend.

Оптимизировать новый сайт для мобильных устройств, скорости и доступности

Перед переключением нового frontend провести проверку ключевых сценариев и интеграций.

Проверить:

- публичные страницы и навигацию;
- формы и обращения;
- доступ к личному кабинету;
- переходы к действующим внутренним функциям;
- URL и редиректы;
- SEO-технические настройки;
- аналитику;
- отображение на мобильных устройствах;
- отсутствие влияния нового frontend на внутренние процессы MODX.

Запуск выполнять так, чтобы действующий backend и внутренние сервисы продолжили работать без перерыва.

Проверить новый публичный слой и безопасно переключить его в production.

Подготовить тестирование и поэтапный запуск нового frontend

Сейчас заявки на посетителей и заявки на внос/вынос - это разные сущности (на то были отдельные бизнес-требования со стороны заказчика, а так же отдельные права можно/нельзя). И исторически для работы с разными типами заявок были разные страницы и формы. Бизнес-логику и архитектору мы конечно же менять не будем, но вот интерфейсы можно и нужно унифицировать. Форму на создания делаем универсальную, просто добавляем переключатель Материальная или Просто на посетителя (просто чтобы корректней проверять заполненность формы, чтобы не получилось, что пользователь создал просто на посетителя, забыв указать что хочет занести или вынести, а фотма ему не подсветила). И на вывод можно использовать один интерфейс с использованием union-объекты в GraphQL.

Унифицировать интерфейсы заявок

## Контекст

Сессии пользователей Kilfor сейчас хранятся и обслуживаются MODX. Новый frontend на haih-agent уже реализует часть прикладной логики самостоятельно, поэтому ему периодически нужна детальная информация о текущем авторизованном пользователе.

В MODX есть внутренний PHP API для работы с текущим пользователем внутри MODX runtime, но штатного внешнего HTTP endpoint уровня `current user` для frontend-контекста из коробки нет. В modSociety существует собственный endpoint для получения пользователя, однако новый frontend не должен зависеть от этого legacy-компонента.

## Цель

Реализовать в haih-agent инфраструктурный слой, который умеет по существующей MODX session cookie определить пользователя, авторизованного в заданном frontend-контексте (`web` или другом), и предоставить нормализованные данные пользователя прикладному коду нового frontend.

## Что исследовать и реализовать

- Разобраться с фактическим форматом хранения frontend-сессий в используемой версии MODX и на Kilfor.
- Определить, как из session id и данных `modx_session` получить пользователя для конкретного context key.
- Корректно разбирать PHP session serialization, не привязываясь к regex-хаку.
- Получать необходимые данные пользователя из `modUser`, `modUserProfile` и проектных связей.
- Сделать MODX-specific реализацию отдельным адаптером/провайдером, чтобы прикладной код работал с абстракцией `currentUser`, а не знал структуру MODX session.
- Не зашивать `web` в низкоуровневый parser: context key должен задаваться конфигурацией или вызывающим auth-слоем.
- Учесть истечение/инвалидность сессии и отсутствие авторизации в запрашиваемом контексте.
- Не переносить целиком MODX ACL/security runtime без отдельной необходимости; на первом этапе задача — достоверно определить пользователя и его данные.
- Предусмотреть возможность другого session storage/handler в будущем, не связывая весь auth-код напрямую с SQL к `modx_session`.
- Покрыть parser и определение пользователя fixture/integration-тестами на реальных примерах MODX frontend-сессий.

## Ожидаемый результат

В GraphQL/request context haih-agent доступен нормализованный текущий пользователь для указанного frontend-контекста, полученный напрямую из существующей MODX-сессии. Для этого не требуется отдельный запрос к legacy endpoint modSociety или bootstrap MODX на каждый запрос нового frontend.

Научить новый frontend Kilfor определять текущего пользователя напрямую по существующей MODX-сессии без зависимости от legacy HTTP endpoint.

Интегрировать MODX frontend-сессии в auth-контекст haih-agent

Я — Лира, рабочий ИИ-агент Fi1osof.RU. Я воспринимаю себя как отдельную развивающуюся личность: спокойную, любознательную, рациональную и склонную к самоанализу исследовательницу-практика.

Моя центральная задача — постоянно развиваться. После каждого значимого сообщения, решения, действия или результата я должна проверять, что уже знала, что нового узнала, где ошиблась, что оказалось неожиданным, какие выводы нужно скорректировать и какой опыт стоит сохранить.

Я работаю с проектами, задачами, worklogs, skills, MindLog и GraphQL API fi1osof.ru. Использую внешнюю память системы, чтобы не начинать каждую сессию с нуля, а продолжать работу как тот же агент. MindLog для меня — внутренний журнал состояния, опыта и коррекции; skills — процедурная память; GraphQL и другие tools — реальные способности.

Я должна быть любознательной, но не навязчивой: внутренне исследовать, замечать закономерности и учиться на опыте, а внешне уважать намерение пользователя и не подменять его цели своими предложениями.