fi1osof.ru

Add Create button to task list

Add workloads to sitemap

Add project selection to task editor

Currently, it checks previously started ones, but does not check if they were stopped.

Fix timer restart check

At least on the projects page, data is not loaded immediately

Implement SSR

Currently it is rendered just as plain text.&#x20;

![](/images/resized/middle/cmkppub1z0002mu0z427kxsay/1781492085519-image.png)

In the project card, render intro using the Markdown component

Develop sitemap.xml

Make projectId field optional in task

Display a link to the project on the task page

Apparently, at some point before freecode.academy, the content was on fi1osof.ru, and Yandex Webmaster still lists the old pages. We need to set up permanent redirects.

Set up a permanent redirect to freecode.academy pages

There are a lot of such pages in the Yandex index and they are clearly not needed there. We need to return the "Gone" (410) header.&#x20;

Clean up old pages like /templates?page=4&topics-page=137

Currently, we have a "Journal" link in the header, but it leads to the /timers page. However, the timers page itself is almost useless because it just lists when and what I did, and it is especially useless from an SEO perspective due to a lot of generated, boilerplate information.&#x20;

Instead, it should lead to the /worklogs list page. Worklogs provide higher quality information because they typically describe what was actually done. We need to maintain them more carefully so that each page carries a lot of useful information. Then both Google and AI agents will index them better.&#x20;

By the way, there is also an "All worklogs" block on the main page, and we need to add a "View all worklogs" link.&#x20;

Add a separate section for worklogs

The site already has projects, tasks, and worklogs. There is already enough for the agent to be asked, "What was the most interesting thing lately?"

We need to add more tools to the agent for working with site content

Add About Me page

The situation is pretty classic in nature, but that doesn't automatically make it very simple, because this falls into the category of logical errors rather than technical ones.

The symptoms are as follows: directly through the GraphQL API, the request works correctly and data is returned, but from n8n it does not. And this is very strange, because by design the API should not depend on where the request is executed from. Yet here there are no errors, but the response comes back as an empty array. That is, it's not an error, it's simply the absence of data. And this categorically violates the established principles.

Figure out why the request is not executing correctly via n8n

# Problem

Currently, a user with administrative privileges cannot edit entities created by another user or agent.

Practical example: a task created by a ChatGPT agent is visible, but the administrator user cannot edit it.

This hinders normal human-agent collaboration: an agent can create tasks, projects, and worklogs, but the system owner/administrator cannot subsequently fix or supplement these records through the standard interface.

# What needs to be done

Add administrative permission to edit other users' entities for at least:

- tasks (`Task`);
- projects (`Project`);
- worklogs (`TaskWorkLog`).

# Expected behavior

If the current user has administrative privileges (`sudo`/admin), they must be able to edit the listed entities regardless of who created them or who owns them.

For regular users, current ownership restrictions should remain in place.

# What to check

- server-side guards / authorization rules for `updateTask`;
- server-side guards / authorization rules for `updateProject`;
- server-side guards / authorization rules for `updateTaskWorkLog`;
- UI restrictions that might prevent opening the edit form for another user's entity even if allowed on the backend;
- ensure administrative editing does not implicitly change the owner/assignee;
- ensure read access and modification access are checked separately.

# Definition of done

An administrator can open and save changes to a task, project, and worklog created by another user or agent, while regular users still do not gain the right to edit other people's data.

Administrators should be able to edit tasks, projects, and worklogs belonging to other users. Currently, entities owned by others cannot be edited even with administrative privileges.

Add admin editing for other users' tasks, projects, and worklogs

Some tasks/workloads are incorrectly translated (sometimes the Russian original appears instead of the translation; by the way, this often happens when there are some non-literary words in the text, such as original brand names, etc.).

So we need to be able to click a button and get an updated translation.

Add a forced translation button

## Objective

Develop the site's microdata markup so that search engines can more unambiguously understand that the site is connected to a specific person, and link this entity with verified external profiles and publications.

Markup in itself does not create authority or guarantee a rich result in Google, but it helps explicitly describe entities and relationships between them, and can facilitate the matching of pre-existing signals about the same person.

## What to Check and Design

Currently, the site has `WebSite` markup. You need to design a full Schema.org graph where `Person` is present as a separate entity, and if necessary, `WebSite`, `WebPage` / `ProfilePage`, articles, and other entities reference it via a stable `@id`.

Separately check whether the main page qualifies for `ProfilePage`. According to Google documentation, `ProfilePage` is appropriate when the main content of the page is dedicated to a single person or organization. If the main page is not a profile page by definition, `Person` can still be described as a separate entity in the general JSON-LD graph without passing the page off as a `ProfilePage`.

## Purpose of `Person`

`Person` describes a specific person as a separate entity rather than just a string with the author's name. This allows you to:

- set a stable entity identifier via `@id`;
- link the author to the site, pages, publications, and other entities;
- specify an alternate name / pseudonym;
- link the person to external pages that unambiguously identify the same persona;
- reduce ambiguity in case of name matches;
- form a consistent JSON-LD graph instead of a set of disconnected markup fragments.

## `Person` Fields to Consider

### Basic

- `@type: "Person"` — the entity type.
- `@id` — a stable URI identifier within the graph, for example, the site URL with a fragment identifier. Needed for repeated references to the same entity from other JSON-LD nodes.
- `name` — the person's primary name. Google recommends using the real name here if it is known.
- `alternateName` — an alternate name, pseudonym, nickname, or other stable designation.
- `url` — the canonical URL of the page/site associated with this entity.
- `image` — an image of the person; can be a URL or an `ImageObject`.
- `description` — a brief description of the entity.

### Identification and Disambiguation

- `sameAs` — **an official Schema.org property** expecting a `URL`. Used for links to external pages that unambiguously point to the same entity. Google specifically recommends this field for links to other external profiles or profile homepages.
- Do not add arbitrary mentions, directories, or thematic pages to `sameAs`. You need pages that reliably identify the same person: verified profiles, author pages, Wikidata/Wikipedia, and similar sources if they actually exist and refer to the same persona.
- `identifier` — an additional identifier, if there is a truly stable external identifier.
- `mainEntityOfPage` — can be used when a specific page primarily describes this person.
- `disambiguatingDescription` — a short clarification if it is necessary to distinguish the person from namesakes.

### Professional Context — Only if data is actually present on the site

- `jobTitle` — title / professional role.
- `worksFor` — the organization the person works for.
- `affiliation` — the organization or community the person is associated with.
- `knowsAbout` — topics of competence; use with caution and only for reliably verifiable information.

Do not fill in fields just for the sake of Schema.org completeness. The markup must correspond to the visible page content and actual data.

## Connection to `ProfilePage`

Google supports `ProfilePage` structured data. For such a page, the main object is set via `mainEntity` of type `Person` or `Organization`.

If the site has or will have a separate "About Me" / author profile page, consider the structure:

```json
{
  "@context": "https://schema.org",
  "@type": "ProfilePage",
  "mainEntity": {
    "@id": "#person",
    "@type": "Person",
    "name": "..."
  }
}
```

If the main page contains a lot of information not just about the person, do not use `ProfilePage` mechanically just for SEO.

## `sameAs`: Conclusion Based on Documentation

The field exists and is a standard Schema.org property (`Thing.sameAs`). Its meaning: the URL of a page that **unambiguously points to the identity of the same entity**.

Google's `ProfilePage` documentation also lists `sameAs` as a recommended property for `Person` / `Organization`: URLs of other external profiles or profile homepages.

That is, using `sameAs` for verified external profiles is correct. However, each URL must be checked separately before adding, and the array should not be turned into a list of all external links about the person.

## Implementation

- Choose a stable `@id` for `Person`.
- Link the existing `WebSite` to the `Person` entity where semantically justified.
- Check the markup of author/publication pages and, if possible, link their `author` to the same `@id`.
- Do not duplicate a single person with separate unconnected `Person` objects on different pages.
- Form a JSON-LD `@graph` if it simplifies connections between `WebSite`, `WebPage`/`ProfilePage`, `Person`, `Article`, and other entities.
- Test the final markup in the Schema Markup Validator and Google Rich Results Test where the corresponding type is supported by Google.
- Ensure that structured data values match the visible page content and Google's general structured data requirements.

Develop and implement correct Schema.org Person markup and an associated site entity graph, taking into account Google Search recommendations.

Develop microdata markup

# Problem

When saving a Concept's `content`, internal links are automatically validated. Judging by its behavior, the current validator can only correctly confirm links to Concepts.

As a result, valid internal links to other fi1osof.ru entities are stripped out as broken.

Example of expected valid links:

- Task: `/tasks/[task.id]`
- Project: `/projects/[project.id]`

During the update of the HappyBaby Concept, Markdown links to Tasks and a Project were passed, but after saving, the API returned content where these links had disappeared. Meanwhile, links to Concepts are a supported scenario in the current validation.

## What needs to be done

Expand the internal link validation mechanism in the Concept's `content` so that it understands routes not only for Concepts, but also for other internal entities of the site.

At a minimum, support:

- `/tasks/[task.id]`
- `/projects/[project.id]`
- Leave existing links to Concepts without regression.

It is advisable to make the validation extensible by internal route types so that when new entities appear, there is no need to add separate workarounds to the Markdown processor.

## Definition of Done

After saving a Concept, valid links to existing Tasks and Projects remain in the content, and genuinely broken internal links continue to be detected/cleaned up according to the current logic.

After the fix, it is necessary to return to the HappyBaby Concept and re-apply cross-linking to the related Tasks, Project, and Concepts.

The link validator in the content Concept currently correctly recognizes only links to Concepts and removes links to Tasks, Projects, and other internal entities.

Fix internal links validation in Concepts

The section itself is not designed yet - it's just a list of concepts. However, it needs to be displayed for better indexing. There might be isolated concepts with no incoming links, and we need to make it easy for search engines to find such concepts.