fi1osof.ru

Starting the timer should automatically move the task to the In Progress status

Draft version:



```ts
 
type FetchWithProgress = (
  input: RequestInfo | URL,
  init?: RequestInit & { onUploadProgress?: (percent: number) => void },
) => Promise<Response>

const fetchWithUploadProgress: FetchWithProgress = (input, init) => {
  const onProgress = init?.onUploadProgress

  if (typeof window === 'undefined' || !onProgress || !init?.body) {
    return fetch(input, init)
  }

  return new Promise<Response>((resolve, reject) => {
    const xhr = new XMLHttpRequest()
    xhr.open(init.method || 'POST', input.toString())

    if (init.headers) {
      const headers = init.headers as Record<string, string>
      Object.entries(headers).forEach(([key, value]) => {
        xhr.setRequestHeader(key, value)
      })
    }

    xhr.upload.onprogress = (event) => {
      if (event.lengthComputable) {
        const percent = Math.round((event.loaded / event.total) * 100)
        onProgress(percent)
      }
    }

    xhr.onload = () => {
      resolve(
        new Response(xhr.responseText, {
          status: xhr.status,
          statusText: xhr.statusText,
        }),
      )
    }

    xhr.onerror = () => reject(new Error('Network error'))
    xhr.onabort = () => reject(new DOMException('Aborted', 'AbortError'))

    if (init.signal) {
      init.signal.addEventListener('abort', () => xhr.abort())
    }

    xhr.send(init.body as XMLHttpRequestBodyInit)
  })
}


```

Add upload progress to apollo-client

Overall, all the functionality is already there from the haih-agent, we just need to expose it and style it a bit.

Add Blog

Configure Varnish caching server

Add multilingual support

Boost SEO/GEO

# Goal

Bring AI collaboration to the next level: the user defines a **working goal** in natural language, for example:

> "Find out why project X is not working"

After that, the agent independently goes through the process from finding the project and gathering context to testing hypotheses and recording the results in fi1osof.ru.

## Target Scenario

Example of the desired workflow:

1. Find the project by name or ID.
2. Get its current context.
3. Read related tasks.
4. Read recent worklogs.
5. View recent events/changes for the project.
6. Check website/API/services availability, if applicable.
7. Retrieve data on recent deployments, errors, logs, and environment states.
8. Formulate several hypotheses for the cause of the problem.
9. Test the hypotheses that can be checked with available tools.
10. Create a new task or update an existing one.
11. Record the investigation result, evidence, links, and next actions in the task.

Roughly:

```text
find project
→ gather recent changes
→ view open tasks
→ read recent worklogs
→ check website/API availability
→ view errors and deployments
→ formulate hypotheses
→ test available hypotheses
→ create/update task
→ record investigation result
```

# What Already Exists

The GraphQL API already provides the basic entities needed to start such a process:

- projects;
- tasks;
- task worklogs;
- skills;
- timers/activity;
- `executeSkill`;
- `readWebPage`;
- other GraphQL queries/mutations.

This already makes it possible to implement part of the agent loop without separate external orchestration.

# What is Missing

## 1. Standardized Technical Project Context

It should be possible to unambiguously retrieve technical sources related to the project:

- repositories;
- services;
- production/staging/dev environments;
- public and internal URLs;
- API endpoints;
- deployments;
- CI/CD runs;
- logs;
- errors;
- monitoring;
- configuration;
- documentation.

Without this, the agent can analyze tasks and work history well, but is not always able to determine the technical root cause of an incident.

## 2. Explicit Entity Relationships

It is desirable to have a machine-readable relationship graph, for example:

```text
Project
├─ Repository
├─ Service
│  ├─ Environment
│  ├─ Endpoint
│  ├─ Deployment
│  └─ LogSource
├─ Task
│  └─ TaskWorkLog
└─ Documentation
```

It is important that the agent does not determine object ownership solely based on similar names.

## 3. Activity Feed / Change History

A unified way is needed to answer the question:

> "What changed right before the problem occurred?"

Useful events:

- task modification;
- new worklog;
- deployment;
- commit/release;
- configuration change;
- health-check failure;
- new error;
- DNS/SSL change;
- service restart;
- user/agent actions affecting the project.

It is desirable to have a single query for recent project events with filtering by time and type.

## 4. Secure Hypothesis Testing Tools

The agent needs read-only or controlled diagnostic actions, such as:

- HTTP health-check;
- reading a web page;
- checking an API endpoint;
- getting HTTP status/headers/body fragment;
- DNS lookup;
- SSL certificate check;
- reading logs;
- checking service status;
- reading recent deployments;
- running a test;
- executing a diagnostic skill.

Part of this can be built on top of existing `readWebPage` and `executeSkill`.

## 5. Autonomy Policy

It is necessary to explicitly define which actions the agent can perform autonomously.

### Allowed Without Additional Confirmation

- read data;
- search for a project and related entities;
- perform read-only diagnostics;
- formulate hypotheses;
- read logs and monitoring;
- create a diagnostic worklog;
- create a regular task if it is a natural result of the investigation;
- supplement the task with diagnostic results.

### Only Upon Explicit User Command

- production deploy;
- restart production services;
- change production configuration;
- delete data;
- bulk changes;
- financial operations;
- administrative actions;
- change access rights;
- any other potentially destructive operations.

# High-Level Skills

Not only low-level skills like "get list of tasks" are needed, but also working-goal level procedures.

Possible skills:

- `investigate_project`
- `check_project_health`
- `analyze_recent_failures`
- `summarize_project_state`
- `investigate_incident`
- `analyze_recent_changes`

For example, `investigate_project` can define a reproducible procedure:

```text
resolve project
→ collect context
→ collect recent activity
→ inspect tasks/worklogs
→ run health checks
→ inspect deployments/errors/logs
→ produce hypotheses
→ test hypotheses
→ persist findings
```

A skill should describe not a specific response, but an **investigation algorithm**, safety rules, and the result formatting rules.

# Investigation Result Format

It is desirable to save the result in `Task.content` or a worklog in Markdown.

Example structure:

```markdown
# Investigation Result

## Symptom
...

## What Was Checked
- ...
- ...

## Observations
- ...

## Hypotheses
1. ...
2. ...

## Confirmed Cause
...

## Evidence
- [log / URL / deployment / commit](...)

## What Was Done
- ...

## Next Actions
- [ ] ...
- [ ] ...
```

# Important Task Storage Principle

For tasks in fi1osof.ru, observe the separation:

- `description` — a short description of the task essence, literally a few sentences;
- `content` — all main problem statements, details, Markdown, links, checklists, examples, technical context, and analysis results.

Do not use `description` as the main long task field.

# First Practical Stage

Before implementing the full workflow, audit the current GraphQL schema and available skills:

1. Determine which of the listed data sources already exist.
2. Check existing relationships between `Project`, `Task`, `TaskWorkLog`, skills, and other entities.
3. Find available operations for web/API diagnostics.
4. Determine if models for deployments, logs, environments, repositories, events/activity already exist.
5. Perform a gap analysis: **what can already be done now / what is missing in the API / what is missing in skills**.
6. Based on this, design a minimal `investigate_project` workflow.

# Definition of Done

A task can be considered implemented when a command like:

> "Find out why haih.net is not working today"

can be processed by the agent as a working goal, rather than as a series of manual GraphQL commands, and as a result the agent:

- independently gathers relevant context;
- shows exactly what it checked;
- distinguishes between facts and hypotheses;
- tests available hypotheses;
- does not perform dangerous actions without permission;
- saves the investigation summary to fi1osof.ru.

Design and implement a secure workflow where an AI independently gathers project context, tests hypotheses, and records investigation results based on a single goal.

Agentic Project Troubleshooting Mode

# Problem

Currently, the roles of task participants are not clearly visible enough in the task interface. It is important for the user to immediately understand:

- who created the task;
- who is responsible for its execution.

This is especially critical in human-AI agent collaboration, as well as in teams where the creator and the executor are often different people.

# What needs to be done

Add the display of two separate roles:

- **Creator** — the user/agent who created or assigned the task;
- **Assignee** — the user/agent to whom the task is assigned.

# Where to display

## Task list

Each row/card in the list should display:

- the creator;
- the assignee.

The display should be compact and not overload the list.

## Task card

In the detailed task card, both roles must be displayed explicitly and separately, with clear labels.

# What to check

- which GraphQL fields already contain creator / author / owner / assignee;
- whether there is a difference between the actual task creator and the task author/assigner;
- whether users and AI agents are displayed correctly;
- what happens if no assignee is set;
- what happens if the creator and the assignee are the same user;
- to ensure the roles are not merged into a single interface field.

# Expected behavior

When opening the task list or task card, the user immediately understands without extra actions:

> who created the task and who is responsible for it.

# Definition of Done

- both roles are visible in the task list;
- both roles are visible in the task card;
- the creator and assignee are displayed as separate entities;
- both regular users and AI agents are correctly supported;
- an unassigned task clearly indicates that, e.g., "Unassigned".

The task interface needs to explicitly display both the creator and the assignee in both the task list and the specific task card.

Show creator and assignee in the task list and task card

# Why This Is Needed

The current session provides good short-term context, but by itself, it should not be the sole source of memory. Upon starting a new session, the agent must be able to restore its working state from fi1osof.ru and continue operating as if it were the same working agent rather than a new model starting "from scratch."

The goal is to build an external, verifiable, and human-managed long-term memory for the agent.

# Core Agent Needs

## 1. Context Restoration at New Session Start

When starting a new session, the agent needs a minimal bootstrap context:

- who the current user is;
- who the agent itself is;
- active projects;
- open and recently modified tasks;
- recent worklogs;
- important decisions and constraints;
- relevant skills;
- recent activity;
- when necessary, current user or project priorities.

It is important not to load everything blindly. The bootstrap must be compact, with deeper knowledge fetched as needed.

## 2. Separation of Memory Types

It is desirable to explicitly distinguish several memory levels:

### Short-Term Memory

The current dialogue and context of the current session.

### Operational Memory

What is needed for ongoing work:

- projects;
- tasks;
- statuses;
- worklogs;
- recent events;
- current blockers.

### Long-Term Factual Memory

Stable knowledge that should persist across individual tasks and sessions:

- architectural facts;
- project specifics;
- confirmed causes of past incidents;
- important technical dependencies;
- stable rules and constraints.

### Decision Memory

Separately storing decisions made by a human or a team:

- what was decided;
- why;
- what alternatives were considered;
- when the decision was made;
- by whom it was made;
- which projects/tasks it applies to.

### Procedural Memory

Skills, runbooks, and reproducible ways of working:

- how to investigate a project issue;
- how to verify a release;
- how to file a bug report;
- how to complete a task after verification;
- how to perform repetitive operations safely.

### Agent Inferences

AI hypotheses and interpretations must be stored separately from confirmed facts and explicitly marked as agent inferences.

# 3. Knowledge Accumulation During Work

The work cycle should not end simply with a chat response.

While performing work, the agent must be able to capture:

- new facts;
- observations;
- verification results;
- causes of errors;
- decisions made;
- useful links;
- inferences;
- constraints;
- lessons worth reusing.

At the same time, not every message and every intermediate inference should become long-term memory.

A selection mechanism is needed: **what is actually worth remembering for the long term.**

# 4. Memory Consolidation

Over time, raw data needs to be condensed into more compact knowledge.

Example:

```text
10 investigation worklogs
→ root cause
→ decision made
→ useful lesson
→ new skill/runbook if necessary
```

Otherwise, long-term memory quickly turns into an event history that is expensive and difficult to reread.

Consolidation must preserve links to primary sources.

# 5. Retrieval by Current Goal

A new session should not reread all memory.

If a user asks about a specific project, the agent should receive the relevant knowledge subgraph:

```text
Project
→ current tasks
→ recent worklogs
→ related decisions
→ relevant facts
→ lessons
→ skills
→ recent activity
```

In other words, memory must support retrieval by:

- project;
- task;
- user/agent;
- entity;
- topic;
- time range;
- knowledge type;
- relationships between entities.

# 6. Provenance and Knowledge Trust

For substantial knowledge, it is desirable to store provenance:

- source;
- author;
- creation date;
- last verified date;
- related project;
- related tasks/worklogs;
- confidence level;
- relevance status;
- links to primary data.

The agent must not treat every saved record as absolute truth.

At a minimum, it is necessary to distinguish between:

- confirmed fact;
- human decision;
- observation;
- agent inference;
- hypothesis;
- obsolete knowledge;
- active instruction/skill.

# 7. Knowledge Updates and Obsolescence

Memory must be able to change.

Provisions must be made for:

- superseding old knowledge with new;
- tagging as `outdated` / irrelevant;
- reassessing hypotheses after new data arrives;
- change history;
- the ability for a human to correct or delete incorrect knowledge.

Contradictory facts must not be silently "glued" together into one.

# 8. Evolution of Skills

A recurring successful workflow should be able to transform into a skill.

Desired cycle:

```text
observation
→ action
→ result
→ recording
→ verification
→ consolidation
→ reuse
→ transforming repetitive experience into a skill
```

Thus, the agent develops not only through the accumulation of facts, but also through the accumulation of procedures.

# 9. Human Control

Long-term memory must not be a hidden model state.

The user must have the ability to:

- see what the agent considers knowledge;
- view the source;
- correct a record;
- mark it as outdated;
- delete it;
- increase or decrease trust;
- explicitly pin a decision as authoritative.

This is critical for collaboration.

# 10. Potential Entities

It is necessary to examine to what extent the current fi1osof.ru model already covers these needs.

Potentially, existing or new entity levels could be used:

- `Fact`;
- `Concept`;
- `Decision`;
- `Observation`;
- `Lesson`;
- `KnowledgeSpace`;
- `Skill`;
- `Task`;
- `TaskWorkLog`;
- relationships between them.

It is not strictly necessary to create new entities if the required semantics are already correctly expressed by the existing model.

# Desired Agent Lifecycle

## Session Start

1. Identify user and agent.
2. Load minimal bootstrap context.
3. Retrieve relevant skills and constraints.
4. Restore the active workspace.

## Performing Work

1. Receive user goal.
2. Fetch relevant knowledge.
3. Verify their relevance where important.
4. Execute the work.
5. Record the result in working entities.

## Completion of a Significant Stage

1. Determine if new long-term knowledge has emerged.
2. Save facts/decisions/observations/lessons.
3. Link them to primary sources.
4. Update existing knowledge instead of creating duplicates, if necessary.

## Periodic Consolidation

1. Find repetitive or fragmented knowledge.
2. Condense them into a compact representation.
3. Preserve provenance.
4. Mark obsolete records.
5. Extract repeatable procedures into skills.

## Next Session

A new agent instance restores state from fi1osof.ru and continues working, using external memory as the source of truth regarding previous experience.

# What Needs to Be Studied

At the next stage, it is necessary to examine the current capabilities of fi1osof.ru and determine:

1. Which existing entities are already suitable for long-term memory.
2. How `facts`, `concepts`, `knowledge spaces`, and their links are structured.
3. Whether there are models for decisions, participants, projections, conflicts, and constraints that can be used instead of new entities.
4. How knowledge search/retrieval works.
5. How knowledge entities are linked to projects, tasks, users, and agents.
6. How to implement provenance and relevance.
7. How best to organize a new session bootstrap.
8. What skills already exist for working with knowledge.
9. What is missing from the API or data model.

# Architecture Readiness Criterion

A solution can be considered successful if, after starting a new session, the agent is able based on fi1osof.ru data to:

- understand who it is and who it is working with;
- restore relevant working context;
- remember important decisions and facts from past sessions;
- not confuse hypotheses with confirmed knowledge;
- determine the provenance of knowledge;
- notice that knowledge has become outdated;
- use accumulated experience in new work;
- progressively turn repeatable processes into skills;
- allow a human to fully control and correct this memory.

Core principle: **the agent's memory must be external, structured, verifiable, and editable, and a new session must restore working state from it rather than starting from scratch.**

Determine how an AI agent should accumulate, verify, and restore knowledge between sessions to prevent losing working context and to progressively improve its skills.

Long-Term Memory and AI Agent Lifecycle

# Context

haih-agent already has its own agentic infrastructure: identity, data access, knowledge management, tools, reasoning, and the ability to autonomously execute tasks.

The issue is not the lack of agentic capabilities as such.

The main practical factor is the **cost of LLM calls**.

When haih-agent operates, every request to the model is billed separately. The higher the quality of the model used, the larger the context, and the longer the agentic loop, the more noticeable the expenses become. As a result, one constantly has to balance between:

- reasoning quality;
- number of steps;
- context size;
- model selection;
- autonomy;
- execution cost.

In ChatGPT, with its subscription-based model, this factor is felt significantly less: one can conduct a long dialogue, reason extensively, clarify, analyze, and execute a sequence of actions with practically no thought given to the price of each individual LLM call.

# Core Need

It is necessary to give the user the ability to use ChatGPT as a full-fledged working environment for interacting with their own system and agent, so that a significant portion of intellectual work can be performed without constant budget monitoring for each request.

At the same time, the integration must not turn ChatGPT into a separate entity isolated from haih-agent with a different memory, a different state, and an unconnected work history.

# Needs the Integration Must Cover

## 1. Cost-Efficient Interactive Work

The user should be able to, without fear of cost:

- discuss a task for a long time;
- clarify requirements;
- analyze data;
- decompose goals;
- form hypotheses;
- compare options;
- perform sequential checks;
- create and refine tasks;
- conduct a long working dialogue.

The usage economics should not force the user to artificially cut down on reasoning purely to reduce the number of LLM calls.

## 2. ChatGPT Access to Real Working Context

ChatGPT must have access to fi1osof.ru data necessary for full-fledged work:

- users and agents;
- projects;
- tasks;
- worklogs;
- knowledge;
- skills;
- related entities;
- current system state.

Without this, ChatGPT remains an external interlocutor to whom the context must be manually re-explained every time.

## 3. Preservation of a Unified Agent Identity

Work from ChatGPT must be linked to the existing agent in fi1osof.ru.

We must avoid a situation where two independent entities emerge:

- an agent inside haih-agent;
- a "different agent" inside ChatGPT.

Actions, knowledge, tasks, and work results must have a clear author and be linked to the common agent identity where appropriate.

## 4. Shared Working Memory

The results of intellectual work in ChatGPT must not be lost after a session ends.

It must be possible to save to fi1osof.ru:

- tasks;
- worklogs;
- facts;
- decisions;
- observations;
- conclusions;
- links;
- useful instructions;
- investigation results.

The next session should be able to restore the relevant context from the shared system.

## 5. Elimination of Repayment for Already Performed Reasoning

If complex analysis has already been performed in ChatGPT, haih-agent must not unnecessarily repeat the exact same intellectual work from scratch via separate LLM calls.

It must be possible to transfer pre-prepared working context between environments:

- goal;
- confirmed facts;
- found problems;
- hypotheses;
- made decisions;
- constraints;
- required next steps.

It is important to preserve the value of already completed reasoning and avoid paying twice for its full reproduction.

## 6. Ability to Use Strong Models Where It Is More Profitable

Model quality significantly affects the cost of haih-agent's work.

The integration should allow using ChatGPT's strong intellectual capabilities for tasks where reasoning quality is especially important, without forcing the constant translation of the entire agent runtime to an expensive API model.

This is especially relevant for:

- complex analysis;
- architectural decisions;
- ambiguous tasks;
- investigations;
- long reasoning chains;
- working with large context;
- task formulation and refinement.

## 7. Preservation of haih-agent Autonomy

Despite using ChatGPT, haih-agent must remain an independent system.

The integration must not create a dependency where the agent stops working without ChatGPT.

It is necessary to maintain the ability to:

- autonomously execute tasks;
- work via API models;
- use local models;
- run background processes;
- perform actions without an active ChatGPT user session.

ChatGPT should expand interaction options and reduce the cost of certain classes of work, rather than becoming the sole point of existence for the agent.

## 8. Clear Separation of Interactive and Autonomous Work

The needs of two different modes must be defined:

### Interactive Mode

The user is present in the dialogue and actively participates in the process.

Particularly valuable here are:

- rich reasoning;
- quick clarifications;
- long context;
- user-economical intellectual work.

### Autonomous Mode

The user is not in an active dialogue.

Important here are:

- the agent's own runtime;
- background processes;
- schedulers;
- automatic reactions;
- independence from the ChatGPT session.

The integration must account for both modes and not artificially mix them.

## 9. Minimization of Duplication of Agent Loops

ChatGPT and haih-agent potentially have overlapping capabilities:

- reasoning;
- tool use;
- context work;
- planning;
- external API calling.

Unnecessary double execution of the same work by the two systems must be avoided.

It is especially important to prevent scenarios like:

```text
ChatGPT fully analyzes the problem
→ passes it to haih-agent
→ haih-agent again fully analyzes the same problem
→ only after that executes the action
```

Such a process worsens both cost and speed.

## 10. Security and Action Control

ChatGPT gains access to a real working system, therefore server-side restrictions and action transparency must be maintained.

Required:

- identification of the action author;
- access rights;
- audit trail;
- correct operation on behalf of the agent or user;
- restrictions on sensitive operations;
- the ability to understand exactly what was executed via ChatGPT.

Security must not rely solely on LLM behavior—final rules must be controlled by the system.

# User Scenario to Support

The user should be able to open ChatGPT and work roughly like this:

```text
"Show my projects"
"Create a bug"
"Check if it has been fixed"
"Add the result to the worklog and close the task"
"Figure out why the project is not working"
```

At the same time, ChatGPT must have sufficient access to fi1osof.ru to perform such work in the real system, and the results should become part of the shared history of the user and the agent.

The user should not be required to manually transfer data between ChatGPT and haih-agent or unnecessarily pay again for the same analysis via an API model.

# Main Value Criterion

The integration makes sense if it simultaneously provides:

1. a high level of intellectual work and convenience of ChatGPT;
2. significantly lower sensitivity to the cost of each LLM call in interactive work;
3. access to real fi1osof.ru data and actions;
4. preservation of shared memory and agent identity;
5. haih-agent autonomy where it is genuinely needed;
6. absence of redundant re-reasoning between the two environments.

# What NOT to Fix as a Solution Yet

At this stage, the task should describe **needs**, not a pre-selected architecture.

Do not yet consider specific options mandatory, such as:

- direct GraphQL calls from ChatGPT;
- full delegation of requests to haih-agent;
- a separate MCP proxy;
- a single orchestrator;
- a specific memory synchronization scheme;
- a specific division of tool loops.

These solutions must be researched and recorded later in the task worklogs along with arguments, experiments, and results.

# Formulation Readiness Criterion

The formulation is considered complete if it makes clear:

- why haih-agent working alone via paid LLM APIs is insufficient from an economic standpoint;
- why ChatGPT is needed as an additional working environment;
- what data and capabilities must be accessible between the systems;
- why shared memory and identity cannot be lost;
- why it is important not to repay for already performed reasoning;
- why haih-agent must maintain its independence in the process;
- what requirements are imposed on security and control;
- that specific architectural decisions will be determined separately based on the results of further work.

Capture the integration needs of ChatGPT with fi1osof.ru and haih-agent, primarily to reduce the cost of intellectual work and preserve a full agentic context.

ChatGPT Integration with fi1osof.ru and haih-agent: Needs and Requirements

Related task: Investigate why the site is poorly indexed.



Generally, a very strange picture emerges. Google knows who Nikolai Fi1osof Lanets is, but for some reason does not associate the website [https://fi1osof.ru](https://fi1osof.ru) with him&#x20;



**I ask it:** Who is Fi1osof?

**It answers:**

**Fi1osof** (real name — **Nikolay Lanets**) is a well-known Senior Fullstack developer, IT entrepreneur, mentor, and JavaScript stack expert in the Russian-speaking IT community.

Main projects and activities

* **Founder of Freecode Academy**: creator and mastermind behind the [Freecode Academy educational platform](https://freecode.academy/profile/Fi1osof), where he teaches developers modern technologies and helps them develop their careers in IT. \[[1](https://freecode.academy/profile/Fi1osof)]
* **Creator of MODX-Club**: Nikolay gained wide recognition in the web community as the creator of the [MODX.Club](https://modx.club/about) platform and an active contributor. For a long time, he helped develop the ecosystem of this CMS and migrate old websites to a modern tech stack.&#x20;
* **Author on Habr**: under the nickname `Fi1osof`, he publishes technical articles, shares experience working in large companies (such as Luxoft and SberTech), and also presents his pet projects — for example, AI agents for programming automation.&#x20;

If you are interested in a specific project or course of his, I can tell you more about it. Which specific area of his work caught your interest?



**I continue:** What is his official website?

The main official website of Nikolay Lanets (Fi1osof) today is his personal page on [**Freecode Academy**](https://freecode.academy/profile/Fi1osof).

Since he is the founder of this platform, it is here that all up-to-date information about his activities is gathered, including his [project portfolio](https://freecode.academy/projects), mentoring information, and contact details.

You can also follow his activity and publications on major thematic platforms:

* **Professional blog**: his articles and breakdowns of IT cases are published in the Fi1osof profile on Habr.
* **Career resume**: verified work experience and tech stack are available on Habr Career.

Would you like to learn more about his **Fullstack development courses** or check out the **open-source IT projects** he has developed?



Overall, this is correct information, but still, the official website is [https://fi1osof.ru](https://fi1osof.ru)

I will fix it.

Update information about your official website in search engines

# Context

Architectural source of truth: [Human-readable URI system in haih-agent maintains address stability and SEO signals](/concepts/sistema-chelovekoponyatnyh-uri-v-haih-agent-sohranyaet-stabilnost-adresov-i-seo-signaly).

On fi1osof.ru, Concepts are becoming the primary public SEO/GEO pages. Human-readable URLs (ChPU) must systematically correspond to the current name/content of the Concept and not depend on whether the user remembered to manually update the URI.

## What needs to be done

### 1. Forced transliteration update button

In the Concept editing interface, add an explicit action, such as "Update URI / transliteration".

It should:

- recalculate the human-readable URI using the current slugify/transliteration rule;
- display/apply the new URI;
- use the shared URI change mechanism so the old address is preserved via a 301 redirect;
- correctly handle collisions of the new URI.

This is necessary for already existing Concepts and cases where it is required to explicitly rebuild an old or poor slug.

### 2. Automatic transliteration on create/update

When creating a Concept, the URI should be automatically generated from the current `name` using the general ChPU logic.

When updating a Concept, it is necessary to automatically update the transliteration/slug in cases where the name or another field on which the URI depends has changed.

Do not duplicate the slugify algorithm on the frontend: use the shared haih-agent server function.

When changing the URI, the existing `old URI → 301 → new URI` mechanism must be used.

It is important not to create endless churn mechanics: if the calculated URI matches the current one, change nothing.

## SEO meaning

The Concept name is one of the main semantic signals of the page. The URI must reflect the current topic so that:

- keywords are present in the URL;
- new Concepts are created immediately with human-readable URLs instead of CUIDs;
- a renamed Concept does not remain forever with an old meaningless slug;
- canonical URLs and internal links remain consistent;
- old addresses retain accumulated signals via 301 redirects.

## Acceptance criteria

- [ ] The Concept editor has a button for forced recalculation of the URI/transliteration.
- [ ] When creating a Concept, the human-readable URL is generated automatically.
- [ ] When changing the name, the URI is automatically brought to the current slug according to the agreed rule.
- [ ] The shared server-side slugify/transliteration logic of haih-agent is used.
- [ ] When changing the URI, a 301 redirect from the old address is automatically created/used.
- [ ] Re-saving without changing the target slug does not change the URI.
- [ ] A new URI collision is handled safely and explicitly.
- [ ] Regression tests have been added for create, rename, forced refresh, unchanged slug, and collision.

Add a manual Concept transliteration update button and automatically maintain human-readable URLs (ChPU) upon content creation/update.

Add forced and automatic URI transliteration update for Concept

# Goal

Add a separate group of public Concepts to fi1osof.ru for a regular, meaningful work journal and link it to the main page.

## Concepts Types

Basic agreement:

- regular post: `article:default`;
- a separate type/subtype is needed for the weekly report — determine the exact name during implementation;
- provide for expanding the `article:*` family if necessary, without creating excessive classification in advance.

## Daily Posts

Form a meaningful report every day for the previous day.

This should not be a mechanical list of timers. The post should gather into a coherent material:

- what was discussed;
- what was actually worked on;
- which tasks and projects were in focus;
- what problems were discovered;
- what decisions were made;
- what conclusions emerged;
- what questions remained open;
- what is worth paying attention to next.

Source data can be taken from Timers, Tasks, WorkLogs, Concepts, MindLogs/discussions, and other available context sources.

## Weekly Report

A separate report is needed for each week. It should not be a concatenation of seven daily posts, but a higher level of generalization:

- main directions of the week;
- where time actually went;
- what changed in projects;
- the most important results;
- discovered systemic problems;
- conclusions and changes in priorities.

Determine the exact format and Concept type separately.

## Dynamic Part of the Main Page

Display the last 3 journal entries on the main page:

- show the title;
- show the description;
- the post itself can be significantly more voluminous;
- add an **"All logs"** link to the full list.

This part should be formed dynamically and show what the author is actually working on right now.

## Static Part of the Main Page

In addition to the dynamic feed, the main page retains a static part stored directly in the `content` of the root Concept `/`.

Its task is to set the permanent context and main semantic routes: complex live projects, practical AI implementation, legacy/project rescue, consulting experience, strong current directions.

Do not finalize the exact ratio of the static and dynamic parts yet. This needs to be thought through separately after real article posts appear.

## Important Principle

The journal is created not as an internal worklog for the author, but as a public, meaningful layer for a potential client. Even a daily post should be interesting to an external reader and demonstrate competencies, problems, solutions, and the train of thought through real events.

Cross-linking within articles and with the main page can now serve as the main CTA.

Design article:* Concepts, daily and weekly work reports, and display recent posts on the main page.

Develop blog Concepts and the dynamic feed for the main page

This is a general task that will take a long time to complete, as a lot of time is currently spent on communicating with AI, gathering information, fact-checking, publishing, etc. At the same time, the final information may also end up on other websites, not just here.

Research and Content

## Goal

Create a single machine-readable `Person` entity with a permanent identifier on the page [fi1osof.ru/about](https://fi1osof.ru/about):

```text
https://fi1osof.ru/about
```

And use this `@id` on client and own websites to form an unambiguous graph of Nikolai Lanets' professional identity.

## fi1osof.ru/about

- replace the current `Person` with the updated version;
- add `@id: https://fi1osof.ru/about`;
- align `@id` and `url`;
- `alternateName`: `Nikolai Lanets`, `Fi1osof`;
- update `jobTitle` and `description` focusing on system architecture, product creation, AI research, AI-native systems, and technology foresight;
- use a permanent public image URL, not `/_next/static/media/...`;
- keep only personal profiles in `sameAs`;
- remove own websites and projects from `Person.sameAs`;
- for Freecode Academy, use the [Fi1osof personal profile](https://freecode.academy/profile/Fi1osof) rather than the project's home page;
- keep `knowsAbout` at the level of stable areas of expertise rather than libraries;
- keep `BreadcrumbList` as a separate JSON-LD.

## HappyBaby2000

On [happybaby2000.ru](https://happybaby2000.ru/), add `Organization` and `WebSite`, keeping the client's organization as the copyright holder. Link Nikolai via:

```json
"contributor": {
  "@id": "https://fi1osof.ru/about"
}
```

and `creditText` according to his actual role.

Also, add a visible professional signature with a link to [Nikolai Lanets' page](https://fi1osof.ru/about), for example:

```html
<a href="https://fi1osof.ru/about" rel="author" title="Nikolai Lanets — Technical architecture, development and AI integration">
  Technical architecture and development — Nikolai Lanets
</a>
```

Do not use `© Nikolai Lanets` if the client is the copyright holder of the website, brand, and content.

## Other Projects

Choose Schema.org relationships based on the actual role:

- `creator` — for a genuinely created product;
- `founder` — for a founded organization/project;
- `contributor` — for technical participation in a client website.

Do not use `creator` automatically on all client websites.

## Language Versions

All language versions of the page [fi1osof.ru/about](https://fi1osof.ru/about) must describe the same person and use a single `Person.@id = https://fi1osof.ru/about`. Add `hreflang` if necessary.

## Verification

After implementation, verify:

- [fi1osof.ru/about](https://fi1osof.ru/about);
- [happybaby2000.ru](https://happybaby2000.ru/);
- other connected websites;
- [Schema.org Validator](https://validator.schema.org/);
- [Google Rich Results Test](https://search.google.com/test/rich-results);
- source server HTML.

JSON-LD must be present in the final HTML and not depend solely on client-side JavaScript.

## Definition of Done

- single `Person.@id` on [fi1osof.ru/about](https://fi1osof.ru/about);
- correct `sameAs`;
- permanent `image` URL;
- stable `knowsAbout`;
- HappyBaby has `Organization` + `WebSite` with the client as copyright holder;
- Nikolai is specified via `contributor` + `creditText`;
- there is a visible professional signature;
- language versions do not create new Person entities;
- server-side JSON-LD passes validation;
- reusable JSON-LD component prepared for subsequent client websites.

## Related Tasks

- [Boost SEO/GEO](/tasks/cmt7tulwi034wtj0qmz5n3s7h)
- [Work out HappyBaby2000 microdata](/tasks/cmqatead1000ime0undm9p30z)
- [Add HappyBaby2000 copyright](/tasks/cmtpetnx607clpf0qxnzt7k59)

Create a unified Person.@id on fi1osof.ru/about and link client and own projects to it using correct Schema.org relationships.

Connect Nikolai Lanets' professional identity with implemented projects via JSON-LD

It is necessary to implement stable, human-readable URIs for three types of entities on fi1osof.ru:

- projects;
- tasks;
- worklogs.

Currently, links to these entities are tied to IDs. A separate `uri` field with SEO-friendly URLs and server-side link existence validation is already used for concepts; a similar principle is needed for working entities.

Minimum requirements:

1. Add a separate `uri` field or equivalent stable slug/route for Project, Task, and Worklog.
2. Generate human-readable URLs from the entity name/title with a uniqueness guarantee.
3. Do not break existing ID routes: old links must continue to work or correctly redirect to the canonical URI.
4. Use human-readable URLs as the canonical path in internal Markdown links and the interface.
5. Handle entity renaming: the URI should not spontaneously break existing links; a clear stability or redirection strategy is needed.
6. Add server-side validation of internal links, similar to concepts, so that non-existent routes are not saved as valid links.
7. After implementation, update the rules/skill for working with fi1osof.ru: before generating internal links, the agent must read the actual entity `uri` rather than constructing the path from the ID or name.

The goal is to unify projects, tasks, concepts, and worklogs under a single system of stable internal cross-linking.

Add human-readable URIs for the main working entities of fi1osof.ru, similar to concepts.

Implement SEO-friendly URLs for projects, tasks, and worklogs

## What needs to be changed

Currently, worklogs in a task card are displayed in **newest to oldest** order. This is inconvenient for reading the work history within a single task: the sequence of events has to be read from bottom to top.

We need to change the behavior of the worklog block:

- by default, display worklogs **from oldest to newest** so that the history is read chronologically from top to bottom;
- add a sorting switcher to the worklog block itself;
- switcher options: **"Oldest first"** and **"Newest first"**;
- the selected order should be applied immediately to the list without changing the worklog data itself.

## Expected result

When opening a task, the worklog history is read naturally — from the first to the last. If necessary, the user can switch the order and see the most recent entries first.

Make chronological worklog sorting the default and add a display order switcher.

Change worklog sorting inside a task

## Context

When working in local Codex via subscription, stability issues are regularly observed in long chats, especially when the agent starts actively working with images and layouts.

Practical observation:

> "Codex is also vibes-coded. Chats constantly freeze. If it stalls, that's it. No errors, nothing. Just a long wait, then reconnect. You start a new chat, and it goes on. Until it freezes again."

And separately:

> "As soon as it starts working with pictures, it freezes really fast."

Beyond freezes, image generation/processing inside an AI session noticeably consumes context/tokens and can make iterative design work expensive and unstable.

## Hypothesis

Separate reasoning/vision from actual image generation.

Leave the AI agent responsible for:

- understanding the task and UI/visual requirements;
- preparing and refining prompts;
- selecting generation parameters/variants;
- analyzing the resulting images via vision;
- comparing with requirements/references;
- forming the next iteration;
- deciding whether the result is sufficient.

Perform the heavy generation itself locally via **ComfyUI** and suitable local image models/workflows.

Proposed cycle:

```text
requirements / current UI
        ↓
AI agent
        ↓
prompt + generation parameters
        ↓
local ComfyUI
        ↓
image(s)
        ↓
AI vision review
        ↓
prompt / parameter correction
        ↺
```

In other words, use the expensive multimodal model primarily where it is most useful: **for task formulation, reasoning, and result verification**, while offloading mass pixel generation to a specialized local pipeline.

## What to Investigate

1. Set up a reproducible local ComfyUI instance.
2. Select a minimal set of models/workflows for UI mockups, illustrations, and other typical visual development tasks.
3. Define a simple programmatic interface through which the coding agent can run workflows and retrieve results without manual work in the ComfyUI UI.
4. Test whether the agent can independently execute the `prompt → generate → inspect → adjust → generate` cycle.
5. Test working with multiple candidates and selecting the best result.
6. Determine which intermediate data actually needs to be returned to the AI context and what can be stored locally to avoid bloating the session.
7. Investigate whether the image-generation workflow can be isolated from the main coding chat so that visual iterations do not degrade the stability of the primary context.
8. Document real failure modes: ComfyUI freezes, VRAM/RAM shortages, long generation jobs, incorrect prompts, vision-review issues, file accumulation, etc.
9. (Note: missing 9th item in original source numbering skip or just standard list)

## Compare with Current Workflow

Run several identical visual tasks using two approaches:

### A. Current Approach

AI/Codex/ChatGPT handles image generation independently within its multimodal session.

### B. Local Pipeline

AI creates the assignment and verifies the result, while generation is performed by ComfyUI.

For each scenario, track:

- wall-clock time to an acceptable result;
- number of iterations;
- token/context consumption, to the extent it can be measured;
- stability of the main AI session;
- number of freezes/reconnects/restarts;
- quality of the final result;
- amount of manual human intervention;
- local GPU/VRAM/RAM costs;
- how easily the agent can independently diagnose a failed generation.

## Success Criteria

Obtain a working experimental pipeline where a coding agent can invoke local ComfyUI, receive an image, visually inspect it independently, and trigger the next iteration if necessary.

After several real-world tasks, answer the following questions:

- Does this reduce AI context/token consumption?
- Does the coding chat become more stable?
- Does the full cycle to an acceptable result speed up or slow down?
- Is the quality of local models sufficient for real product work?
- Which types of visual tasks are rational to perform locally, and which are more advantageous to leave to an external multimodal/image model?
- Is it worth establishing this pipeline as a permanent tool/skill for AI agents?

## Important Limitation

Do not assume it is pre-proven that Codex freezes are specifically caused by token consumption or model-side image generation. This is an observed correlation that the experiment should help separate from other causes. The goal is to test the practical effectiveness of the alternative workflow, not to pre-explain the internal cause of Codex freezes.

Test whether image generation can be offloaded from Codex/ChatGPT to a local ComfyUI instance, leaving task formulation, prompt engineering, and vision review to the agent, in order to reduce token consumption and freezes when working with images.

Investigate local image generation via ComfyUI for AI agents

It is necessary to master the full cycle, from creating websites and deploying them to a server to subsequent maintenance and monitoring, all using AI tools.

Master the mechanics of managing multiple websites

Actually, this is an old planning system (I have thought it through more than once and even made a couple of working prototypes, but it has too many nuances, which is why I never brought it to completion before).&#x20;