**bizneshelper.ru** is a web project in the field of business consulting and management expertise.

## Project Purpose

The website presents areas of professional assistance to business, publishes expert materials, and serves as a public entry point to get acquainted with the team's approaches, competencies, and experience.

## Topics

The public section of the project features materials related to:

* management and strategic consulting;
* sales and marketing development;
* production and crisis management;
* business processes and organizational changes;
* HR, legal, foreign economic, and other applied areas;
* practical case studies and expert publications.

## Audience

The project is aimed at owners, managers, and specialists of operating companies who need external expertise in management, development, and improving business efficiency.

## Role of the Website

The website simultaneously performs several functions:

* presents competencies and work areas;
* builds trust through public materials and experience;
* accumulates expert content;
* helps visitors understand what tasks they can turn to for consulting assistance;
* serves as a basis for the further development of the project's digital presence.

## Project Management Principle

Only open information is recorded in the project card and related public entities. Internal agreements, financial indicators, access credentials, personal data, client information, and other sensitive data are not published.

## Related Entities

* Technical modernization concept: [bizneshelper.ru — modernization and migration to haih-cms](/concepts/bizneshelper-ru-modernizatsiya-i-migratsiya-na-haih-cms).
* Current work is carried out through project tasks; individual technical initiatives do not define the content of the project itself.

bizneshelper.ru is a website about business consulting, management, and organizational development.

bizneshelper.ru

# Migration of bizneshelper.ru from Ruby to haih-cms

Main project objective.

The goal is to migrate the public website from the existing Ruby implementation to **haih-cms** while preserving significant content, core user scenarios, material accessibility, and search engine compatibility.

All sub-tasks must contain only publicly acceptable wording and exclude internal commercial data, access credentials, secrets, or personal information.

Main project objective: migration of the existing website to haih-cms.

Migration of bizneshelper.ru from Ruby to haih-cms

# Goal

Design a clean target data model for the new website on haih-cms. The legacy Rails model is used only for understanding the source data and should not be copied one-to-one.

## What to Do

- Based on the completed inventory, identify the real entities needed by the new website.
- Design fields and relationships, keeping future editing and project evolution in mind.
- Separately describe the mapping between legacy tables/fields and the new entities.
- Do not carry over technical fields and relationships that only served the old Rails implementation.
- Provide for SEO fields, slugs, publication statuses, and relationships between content items.
- Account for the import of media and related files.

## Result

The target haih-cms schema, optimized for the new website, plus a clear legacy-to-new data transformation map.

## Definition of Done

- All migrated entities have a target representation.
- The legacy structure is not copied unnecessarily.
- Data transformation rules for import are clear.
- The model is suitable for the future evolution of the website independently of the Ruby project.

Design the target data model for haih-cms based on the needs of the new website, using the legacy database solely as a data source rather than an architectural template.

Design the data structure in haih-cms

# Goal

Prepare a working public layer for the new version of the website where all migrated content has proper representation and stable routes.

## What to do

- Implement templates for the main page types identified during the inventory.
- Set up routes for sections, lists, material cards, and service pages.
- Restore main navigation, hierarchy, breadcrumbs, and internal linking.
- Ensure consistent behavior for titles, metadata, images, and related materials.
- Handle empty states, missing entities, and 404s.
- Verify responsiveness and basic accessibility for key templates.
- Coordinate routes with the URL preservation and redirection task.

## Result

A set of working haih-cms templates and routes sufficient to display all core public content.

## Definition of Done

- All key page types open successfully in the new implementation.
- Navigation and links between materials work properly.
- URLs are generated predictably and match the migration map.
- Error and missing routes are handled correctly.
- Pages are ready for further SEO and content testing.

Implement the core page templates, navigation, and routing in haih-cms required to replace the Ruby-based website.

Prepare haih-cms templates and routes

# Objective

Migrate accumulated public content without loss, preserving material structure, images, internal links, and readiness for further editing.

## What to do

- Prepare a method for exporting or extracting public materials from the current implementation.
- Map legacy fields to the target haih-cms model.
- Transfer texts, titles, dates, images, files, and other public attributes.
- Normalize markup where legacy HTML interferes with the new system, without distorting content.
- Preserve internal links and connections between materials.
- Check for broken links, missing images, and incorrect attachments.
- Highlight materials that require manual review after automated import.

## Result

Public content and media are available in haih-cms and match the source materials in meaning and structure.

## Definition of Done

- All planned content types have been migrated.
- Main fields and dates are not lost.
- Media opens correctly and is linked to the appropriate materials.
- Internal links do not point to known non-existent pages.
- A list of manual exceptions has been compiled, if any exist.

## Constraints

Migrate only publicly permissible materials. Non-public data, secrets, internal documents, and personal information must not be included in the migration without separate justification.

Migrate public content and media from the current website to haih-cms with completeness and quality checks.

Migrate public content and media

# Objective

Preserve search continuity where it truly matters, without attempting to replicate the entire historical URL structure of the old site.

## Context

There is a limited number of pages in the search index—around 85. Therefore, full backward compatibility with all legacy routes is not required.

## What to do

- Collect the actual list of indexed and other truly significant public URLs.
- For each URL, determine the target page in the new haih-cms structure.
- Where reasonable, keep the address unchanged.
- For changed addresses, prepare targeted permanent 301 redirects.
- For outdated pages without a useful equivalent, make an explicit decision: merge with a new page or return a correct 404/410 depending on the situation.
- Exclude redirect chains and loops.
- Verify the consistency of the new URL map with canonical tags and sitemap.

## Result

A small, manageable SEO migration map for truly significant URLs instead of maintaining all legacy routing.

## Definition of Done

- All indexed and significant URLs have been resolved.
- Direct 301 redirects are configured for the necessary pages.
- There is no requirement to support the old Rails routing entirely.
- The new URL structure is considered primary and canonical.

Map a limited set of actually indexed and significant legacy URLs to the new site structure and set up targeted 301 redirects.

Prepare SEO map of significant URLs and redirects

# Objective

Implement on the new platform only those forms and public integration scenarios that are required by the new website.

## What to Do

- Based on the inventory results, determine the actually needed forms and user actions.
- Do not migrate legacy form code, Devise/OAuth, or other integrations automatically just because they exist in the old project.
- For each required scenario, design a new implementation using haih-cms and the current stack.
- Set up validation, error messages, and successful submission confirmations.
- Check protection against obvious spam and duplicate submissions.
- Connect external integrations only when there is a confirmed necessity.

## Result

The new website contains an up-to-date set of forms and public integrations without dependency on legacy code.

## Definition of Done

- All necessary user scenarios are implemented.
- Outdated OAuth and other legacy integrations are not migrated automatically.
- Forms operate independently of the Ruby application.
- Sensitive parameters are not recorded in the public task.

Do not migrate legacy form implementations literally; re-implement only the relevant user scenarios on haih-cms.

Re-implement forms and current public integrations from scratch

# Objective

Build the SEO for the new version of the website as an independent system and ensure a controlled transition from a limited set of significant legacy pages.

## What to Do

- Establish title, description, and canonical rules for the new structure.
- Configure robots.txt and sitemap for the new version.
- Ensure that only canonical, accessible pages are included in the sitemap.
- Use the SEO map of significant legacy URLs for targeted transfer of search equity.
- Avoid mechanically replicating old metadata and structures where unjustified.
- Verify heading structure, indexability, and the absence of technical duplicates.
- After launch, verify that search engine crawlers see the new version correctly.

## Result

The new version has its own correct SEO layer and maintains continuity for genuinely important old pages.

## Definition of Done

- Main page types have correct SEO rules.
- Sitemap and robots.txt are functioning.
- Significant old URLs are correctly mapped to the new structure.
- The new structure is considered primary, rather than a copy of legacy SEO.

Create a correct haih-cms SEO layer and transfer search equity only for genuinely significant legacy pages.

Form the SEO layer of the new website and ensure search engine migration

# Objective

Ensure observability of the new website version: understand whether it is available, where errors occur, and whether key user scenarios are functioning.

## What to do

- Define a minimum set of technical and user events to track.
- Restore or reconnect web analytics in the new implementation.
- Set up basic availability monitoring for public pages.
- Ensure logging of critical application errors and failed user actions.
- Verify that main forms and transitions can be diagnosed after launch.
- Make sure data collection does not break the user interface or create excessive requests.
- Prepare a simple set of checks to use in the first few days after switching over.

## Result

The new version of the website has basic observability, and critical issues can be detected without manually browsing the entire site.

## Definition of Done

- Basic analytics loads and records key events.
- Website availability can be monitored automatically or through regular checks.
- Critical errors do not remain completely invisible.
- There is a clear way to test forms and main user scenarios after launch.

## Limitations

Do not publish tracker IDs, tokens, keys, internal monitoring system addresses, or other sensitive parameters.

Configure basic analytics and technical monitoring for the new version of the website after launch.

Configure analytics and technical monitoring

# Objective

Confirm the readiness of the new website to replace the legacy version. Pixel-perfect and functional replication of the old Ruby website is not the goal.

## What to do

- Verify the completeness of entity and content migration according to the migration list.
- Compare the selection of materials and media with the legacy source.
- Test new templates, navigation, forms, and key user scenarios.
- Check the SEO map of important URLs and 301 redirects.
- Check sitemap, robots, canonical tags, and main metadata.
- Test responsiveness and technical errors.
- Do not consider differences from the old interface as defects if the new implementation complies with the target design and functional requirements.

## Result

The new version is confirmed as a standalone working website and is ready to completely replace the Ruby implementation.

## Readiness criteria

- Data and media have been migrated in the agreed-upon scope.
- Key scenarios are working.
- Important old URLs are handled correctly.
- There are no blocking errors before switching.

Test the new implementation as a standalone website: data completeness, scenario correctness, and absence of critical migration errors.

Conduct functional and content testing

# Objective

Safely replace the public Ruby version with the new haih-cms website. After the transition, the old application will be kept as a backup and a reference source for verification, but not as a parallel production system.

## What to do

- Verify the readiness of the new version regarding data, pages, forms, SEO, and redirects.
- Prepare the sequence for a one-time switch.
- Define control checks immediately after launch.
- Maintain the capability for a short-term technical rollback in case of a critical error.
- Do not design continuous data synchronization or long-term operation of both websites simultaneously.
- After successful stabilization, consider haih-cms as the sole active production website.

## Result

There is a simple plan to replace the legacy website with the new implementation and a fallback scenario in case of a critical issue during launch.

## Definition of Done

- Necessary data is migrated before the switch.
- The new version has passed testing.
- Post-launch control checks are defined.
- Parallel operation of the two systems is not required.

Prepare a one-time switch to the new website; continuous parallel operation of the Ruby and haih-cms versions is not required.

Prepare switch to haih-cms and fallback rollback

# Goal

Ensure that after the actual switch, the site operates stably in the public environment and has not lost significant features, URLs, or content.

## What to do

- Check the availability of the main page and key sections from the public network.
- Check the sampling of old URLs and the operation of redirects.
- Check forms and key user scenarios in the production environment.
- Check the loading of images, files, CSS, JavaScript, and other public resources.
- Check robots.txt, sitemap, and canonical addresses.
- Review technical errors and anomalies that appeared after the switch.
- Check mobile display and main browser scenarios.
- Record found regressions and resolve critical ones with high priority.

## Result

It is confirmed that the new version is working in the public environment, and critical consequences of the migration have been resolved.

## Readiness criteria

- Key pages are accessible.
- Forms are working.
- Main old URLs are correctly served or redirected.
- There are no mass resource loading errors.
- No critical indexability issues were found.
- All blocking regressions have been resolved.

Perform an extended check of the new version after launch and fix migration regressions.

Perform post-migration check

# Goal

Make the commercial structure of the website clearer without publishing internal economics, contract terms, and non-public client data.

## What to do

- Analyze the existing public structure of areas and services.
- Group related areas so that the visitor sees clear request scenarios rather than a long list of competencies.
- Highlight main entry points: typical management problems, audits, development of individual functions, change management support, and other publicly verified areas.
- Reassemble case presentations: initial public task, approach, completed work, and publishable results.
- Interlink services, cases, and expert materials.
- Remove obvious redundancies and navigation overload.
- Preserve valuable existing materials and search pages without deleting them unnecessarily.

## Result

A clear public structure of services and cases that helps visitors quickly relate their situation to the project's capabilities.

## Definition of Done

- Main areas are grouped logically for an external visitor.
- Key areas have a clear next step.
- Cases are used as proof of experience, not just as an archive.
- Old expert content is not lost and is linked to the new commercial structure.

## Constraints

Do not publish internal project economics, contract sizes, non-public client metrics, confidential names, and interaction details.

Reassemble the public structure of services and cases so that visitors can more easily understand the value and choose their next step.

Repackage the public structure of services and cases

# Objective

Turn the homepage into an effective entry point to the project: quickly explain what bizneshelper.ru does, who it is useful for, and where to go next.

## What to do

- Formulate a clear hero section based solely on publicly verified information.
- Show the main areas of assistance without overloading with a long service catalog.
- Add clear transitions to key user journeys.
- Use public case studies, expert materials, and team information as trust elements.
- Build a logical sequence of blocks: purpose, client situations, approach, areas, experience, next step.
- Ensure the homepage does not duplicate the encyclopedic structure of the old website.
- Define key landing pages where the main CTAs and navigation should lead.

## Result

A new homepage and a set of key entry points that make the project easier for a new visitor to understand.

## Definition of Done

- The first screens clearly convey what the project does.
- A visitor can choose a suitable direction without studying the entire catalog.
- There are clear transitions to services, case studies, materials, and contacts.
- Public trust elements are integrated into the page structure.
- The homepage works correctly on mobile devices.

Redesign the homepage and key entry points so that the project's purpose and main user scenarios are immediately clear.

Update the homepage and key entry points

# Objective

Ensure that open information on the website is up-to-date, consistent, and does not cause visitor doubt due to outdated data.

## What to do

- Check public information about the project, team, areas of work, and contact methods.
- Find outdated wording, links, mentions of old services, and other signs of obsolescence.
- Check team pages and public biographical information.
- Check contact and organizational blocks in various sections of the website for consistency.
- Update public trust elements: case studies, experience, expert materials, author information, and other proofs of competence.
- Remove or rewrite elements that cannot be reliably verified with open information.
- Escalate all controversial information requiring internal data to a separate approval process and do not publish it automatically.

## Result

The website's public information is consistent and contains no obviously outdated or questionable elements.

## Definition of Done

- Main pages do not contradict each other in terms of public information.
- Outdated contacts and links have been removed.
- Team information and areas of work have been updated within the limits of verified data.
- Unverified claims are not published.

## Limitations

If updating requires non-public legal, financial, client, or personal data, do not include them in the open task; address the issue separately in a private working discussion.

Check and update all public information that affects trust in the project.

Update public information and trust elements

# Objective

Perform a controlled and verifiable migration of structured data from legacy MySQL to the new haih-cms model. This is a separate technical phase independent of the further operation of the Ruby application.

## What to do

- Based on the inventory and target model, determine the tables, fields, and relations involved in the import.
- Prepare the legacy → haih-cms mapping.
- Define conversion rules for slugs, dates, statuses, HTML content, and relations.
- Prepare the import so it can be re-run on a test environment without manually editing each record.
- Handle duplicates, missing relations, and invalid legacy values.
- Separately link record import with the subsequent migration of media.
- After the import, generate a count reconciliation and a spot check of the content.

## Result

A reproducible import transfers a consistent set of data from legacy MySQL to haih-cms with a clear report on skipped or transformed records.

## Definition of Done

- Mapping of source and target entities is documented.
- Import runs independently of any running Ruby application.
- Necessary relations and significant fields are preserved.
- Repeated test runs are predictable.
- Completeness check and an exception list are available.

## Constraints

Dumps, credentials, personal data, and other sensitive information from the source DB are not published in this open task.

Prepare a reproducible, one-time import of required data from the legacy MySQL project into the target haih-cms model.

Design and execute data import from legacy DB to haih-cms

# Context

The current feedback form contains too many fields and requires the user to describe the situation in detail beforehand using a rigid questionnaire. This scenario creates a high entry barrier and increases the likelihood that visitors will not submit their request at all.

## Goal

Make the first contact with the project as simple as possible: users should be able to start a request quickly, while necessary details are gathered gradually through conversation.

## What to Do

- Analyze the current set of form fields and determine the minimum required information for initial contact.
- Remove mandatory fields that can be clarified later.
- Design a short entry scenario: a minimal form or launching a conversation with an AI agent.
- Implement an AI agent that consistently clarifies the task context in natural language instead of a long static questionnaire.
- Make the dialogue adaptive: do not ask the user questions whose answers are already clear from previous messages.
- Provide an option to quickly proceed to submitting the request without going through the long scenario.
- Generate a final structured summary of the request for further processing.
- Provide a clear fallback scenario in case the AI component is unavailable.

## Result

Instead of an overloaded questionnaire, the user gets a simple entry into the request process, and additional details are gathered through a convenient dialogue with an AI agent.

## Definition of Done

- The first step requires a minimal number of actions and fields.
- The user can describe the task in free text.
- The AI agent clarifies only the missing context.
- The request outcome is formatted in a structured way.
- A working non-AI fallback is available.
- The scenario works correctly on mobile devices.

## Limitations

Do not collect excessive personal data and do not publish internal request routing rules, private prompts, API keys, or other sensitive parameters in the public task.

Reduce the overloaded feedback form to a minimal entry point, and shift task clarification to a dialogue with an AI agent.

Simplify the feedback form and replace the questionnaire with an AI agent

# Context

The FAQ section displays a list of questions, but users cannot expand the answers.

One of the probable causes is a previously documented issue with loading legacy jQuery over HTTP on an HTTPS page: the browser blocks such Mixed Content, which can break JavaScript interactivity. This assumption needs to be confirmed through actual testing.

## Objective

Restore the normal user flow for interacting with questions and answers, and migrate the section to the new implementation without reliance on fragile legacy JavaScript.

## What to Do

- Reproduce the issue on the live site and a local legacy copy.
- Check the browser console, network errors, and whether expanding answers actually depends on jQuery/legacy scripts.
- Determine the section's data structure and how questions and answers are stored.
- Implement a working display of questions and answers in the new version of the site.
- Do not blindly port the old JavaScript mechanics if they are no longer needed.
- Ensure correct operation without external insecure dependencies.
- Verify mobile display, accessibility, and navigation within the section.

## Result

The FAQ section works predictably and does not depend on broken legacy interactivity.

## Definition of Done

- The cause of the current defect has been identified.
- Users can access every answer.
- The section works without Mixed Content and without critical dependencies on old jQuery.
- Question and answer data has been correctly migrated to the new system.

In the current legacy section, the list of questions is displayed, but the answers do not expand. We need to identify the cause and ensure the section works properly in the new version.

Fix the FAQ section

# Objective

Make the "FAQ" section more convenient for navigation, linking, and search engine indexing: each question should be a standalone page, and the main section should act as a list or catalog of such pages.

## What to do

- Define the target question entity in haih-cms: question title, answer, slug, publication status, SEO fields, and category if necessary.
- Migrate existing questions and answers to individual entries.
- Generate a human-readable URL for each question.
- Display a list of questions with links to individual pages on the main section page.
- Provide navigation between questions and a way back to the main list.
- Configure title, description, canonical, and other basic SEO fields for the question pages.
- Group questions by topic if necessary, provided it improves navigation without unnecessarily complicating the structure.
- Check for old FAQ links that should be redirected to the new pages.

## Result

Each question and answer exists as a separate public page, and the "FAQ" section acts as a convenient index for such materials.

## Definition of Done

- Each question has a separate, stable URL.
- The main section contains links to all published questions.
- Question pages are indexable and have correct basic metadata.
- The user can open an answer without JavaScript dependency.
- The structure is suitable for further FAQ expansion.

Restructure the FAQ so that each question and answer has its own page, and the main section works as a catalog of questions.

Split "FAQ" into individual question pages

# Context

The current version of bizneshelper.ru has the following Lighthouse baseline:

- Performance: 83
- Accessibility: 46
- Best Practices: 52
- SEO: 92

## Goal

Improve the technical quality of the website across key Lighthouse categories, primarily addressing critical drops in Accessibility and Best Practices, and increasing Performance where possible without degrading functionality.

## What to do

- Generate a detailed Lighthouse report and record the primary causes of point losses.
- Analyze issues by category: Performance, Accessibility, Best Practices, SEO.
- Prioritize and fix errors that contribute most significantly to the drops in Accessibility and Best Practices.
- Check external resource loading, Mixed Content, outdated libraries, and console errors.
- Optimize the critical rendering path, CSS/JS loading, images, fonts, and caching where it actually impacts metrics.
- Check HTML semantics, contrast, alt texts, labels, focus states, and the accessibility of interactive elements.
- Re-run Lighthouse after making changes and compare the results with the initial baseline.

## Result

Measurable improvement in Lighthouse metrics and resolution of key technical defects identified by the audit.

## Definition of Done

- Accessibility and Best Practices are significantly improved compared to the current 46 and 52.
- Performance is not degraded compared to 83 and is increased if possible.
- SEO is not degraded compared to 92.
- The main causes of point losses are documented and either fixed or intentionally postponed.
- There is a final Lighthouse report for comparison with the initial state.

Improve performance, accessibility, Best Practices, and SEO scores in Lighthouse relative to the current baseline.

Improve Lighthouse metrics

# Objective

Provide users with search capabilities over the content of the new unified knowledge base of the site without dependency on the old Rails/Solr infrastructure.

## What to Do

- Index published Concepts and their main text fields.
- Define a simple and intuitive interface for search queries and results.
- Take into account `name`, `description`, `intro`, `content`, and, if necessary, the type/hierarchy of the Concept.
- Handle empty results correctly.
- Do not carry over Sunspot/Solr solely for compatibility with the old site.
- Provide the capability for future development of search towards semantic/AI search on top of the same universal database.

## Result

Search works on the new unified data model and can evolve without being tied to the legacy architecture.

Implement a new search across the unified Concepts database instead of restoring the broken Sunspot/Solr search of the legacy site.

Implement search for Concepts

# Objective

Make the imported legacy content not the final migration result, but the raw material for systematic AI editing.

## Basic Scenario

The AI agent receives:

- original record data from the legacy DB;
- the newly created Concept;
- general project context and rules.

After that, the agent updates the Concept content: reworks the structure, formatting, and presentation while preserving confirmed original facts.

## What to Do

- Define a unified interface for AI processing of Concepts.
- Pass the original legacy data to the agent as factual context, and the new Concept as the editable result.
- At the first stage, work primarily with `content`, without complicating the DB schema with new fields for specific editorial structures.
- Allow the agent to structure the material, add formatting, and internal linking.
- Prohibit inventing unverified facts and commercial results.
- Add result validation before saving: markup correctness, validity of internal links, and other deterministic checks.
- Make the processing repeatable and suitable for mass execution across the imported database.

## Result

After migration, old content is systematically transformed into a modern knowledge base without manual rewriting of every page and without expanding the schema for every type of material.

## Definition of Done

- A single AI pipeline is applicable to different types of Concepts.
- Original facts are preserved.
- The result passes programmatic validation before saving.
- The imported database can be processed in bulk.
- No separate AI code is required for each legacy table.

Following the initial migration of legacy data, automatically reprocess Concepts: structure and format content, preserve facts, improve presentation and internal links.

Develop an AI process for updating imported Concepts

# Context

Tags on the old bizneshelper.ru use short and uninformative URLs like `bz`, `nf`, `kns`, and similar. Such addresses tell the user nothing about the page content, degrade link readability, and do not match the new haih-cms structure.

## Goal

Move tag pages to clear, human-readable URIs generated from normal tag names, and ensure the correct migration of old addresses.

## What to do

- Inventory existing tags and their current URLs.
- Determine a new readable slug for each retained tag.
- Use meaningful URIs based on the tag name, without meaningless abbreviations.
- Check the uniqueness of new slugs and handle collisions.
- Create `301` redirects from old URLs to new ones where necessary.
- Update internal links, sitemap, and canonical tags so that only new addresses are used.
- Verify that old addresses do not continue to appear in the new internal linking structure.
- Do not carry over legacy abbreviations as part of the new model solely for backward compatibility.

## Result

Tags have clear, stable URLs that match their meaning, and old addresses are served only as a compatibility layer via redirects.

## Definition of Done

- All migrated tags have human-readable slugs.
- New URLs are unique and predictable.
- Old significant URLs correctly redirect to the new ones.
- Internal links, canonical tags, and sitemap use the new addresses.
- The new system retains no dependency on meaningless legacy codes like `bz`, `nf`, `kns`.

Replace uninformative legacy tag URLs like `bz`, `nf`, `kns` with clear, human-readable addresses and maintain compatibility through redirects where necessary.

Update tag URLs

Boost SEO/GEO

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

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

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

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