fi1osof.ru

Thêm nút Tạo vào danh sách công việc

Thêm các workload vào sitemap

Thêm lựa chọn dự án vào trình chỉnh sửa công việc

Hiện tại, nó kiểm tra các bộ hẹn giờ đã được khởi động trước đó, nhưng không kiểm tra xem chúng đã bị dừng hay chưa.

Sửa lỗi kiểm tra khởi động lại bộ hẹn giờ

Ít nhất trên trang dự án, dữ liệu không được tải ngay lập tức

Triển khai SSR

Hiện tại đang hiển thị dưới dạng văn bản thuần túy.&#x20;

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

Trong thẻ dự án, hiển thị phần giới thiệu thông qua thành phần Markdown

Triển khai sitemap.xml

Làm cho trường projectId trong tác vụ trở thành tùy chọn

Hiển thị liên kết đến dự án trên trang công việc

Có vẻ như trước khi có freecode.academy, nội dung từng nằm trên fi1osof.ru và Yandex Webmaster vẫn đang liệt kê các trang cũ đó. Chúng ta cần thiết lập chuyển hướng vĩnh viễn.

Thiết lập chuyển hướng vĩnh viễn đến các trang freecode.academy

Có rất nhiều trang tương tự trong chỉ mục của Yandex và chúng rõ ràng không cần thiết ở đó. Cần phải trả về tiêu đề "Đã xóa vĩnh viễn".&#x20;

Dọn dẹp các trang cũ dạng /templates?page=4&topics-page=137

Hiện tại, ở phần đầu trang chúng ta có liên kết Tạp chí (Журнал), nhưng nó dẫn đến trang /timers. Tuy nhiên, bản thân trang bộ hẹn giờ gần như vô ích vì nó chỉ hiển thị danh sách khi nào và tôi đã làm gì, hơn nữa nó hầu như vô ích về mặt SEO do có nhiều thông tin chung chung được tạo tự động.&#x20;

Thay vào đó, nó nên dẫn đến trang danh sách /worklogs. Worklog cung cấp thông tin chất lượng hơn vì chúng thường mô tả chi tiết những gì đã được thực hiện. Chúng ta cần quản lý chúng cẩn thận hơn để mỗi trang đều chứa nhiều thông tin hữu ích. Khi đó cả Google và các tác nhân AI sẽ lập chỉ mục chúng tốt hơn.&#x20;

Nhân tiện, trên trang chủ cũng có khối "Tất cả worklog" và cần thêm liên kết "Xem tất cả worklog".&#x20;

Thêm một phần riêng cho nhật ký công việc (worklogs)

Trang web đã có các dự án, nhiệm vụ và nhật ký công việc. Đã có đủ dữ liệu để có thể hỏi agent câu hỏi "Gần đây có gì thú vị nhất?".

Cần bổ sung thêm công cụ cho agent để làm việc với nội dung trang web

Thêm trang Giới thiệu

Tình huống về cơ bản là khá kinh điển, nhưng điều đó không tự động khiến nó trở nên rất đơn giản, bởi vì đây thuộc về loại lỗi logic chứ không phải lỗi kỹ thuật.

Các triệu chứng như sau: trực tiếp qua GraphQL API, yêu cầu hoạt động chính xác và nhận được dữ liệu, nhưng từ n8n thì không. Và điều này rất kỳ lạ, bởi vì theo thiết kế, API không nên phụ thuộc vào việc yêu cầu được thực hiện từ đâu. Thế mà ở đây không có bất kỳ lỗi nào, nhưng phản hồi lại trả về là một mảng rỗng. Nghĩa là đây không phải là lỗi, mà đơn giản là không có dữ liệu. Và điều này vi phạm nghiêm trọng các nguyên tắc đã đề ra.

Tìm hiểu lý do tại sao yêu cầu không thực hiện đúng cách qua n8n

# Vấn đề

Hiện tại, người dùng có quyền quản trị không thể chỉnh sửa các thực thể do người dùng hoặc tác nhân (agent) khác tạo ra.

Ví dụ thực tế: một công việc do tác nhân ChatGPT tạo ra có thể nhìn thấy được, nhưng người dùng quản trị lại không thể chỉnh sửa nó.

Điều này cản trở sự cộng tác bình thường giữa con người và tác nhân: tác nhân có thể tạo công việc, dự án và nhật ký công việc, nhưng chủ sở hữu/quản trị viên hệ thống sau đó không thể chỉnh sửa hoặc bổ sung các bản ghi này thông qua giao diện thông thường.

# Cần làm gì

Thêm quyền quản trị để chỉnh sửa thực thể của người khác ít nhất cho:

- công việc (`Task`);
- dự án (`Project`);
- nhật ký công việc (`TaskWorkLog`).

# Hành vi mong đợi

Nếu người dùng hiện tại có quyền quản trị (`sudo`/admin), họ phải có khả năng chỉnh sửa các thực thể được liệt kê bất kể ai đã tạo ra hoặc sở hữu chúng.

Đối với người dùng thông thường, các giới hạn quyền sở hữu hiện tại vẫn phải được duy trì.

# Cần kiểm tra

- các guard / quy tắc ủy quyền phía máy chủ cho `updateTask`;
- các guard / quy tắc ủy quyền phía máy chủ cho `updateProject`;
- các guard / quy tắc ủy quyền phía máy chủ cho `updateTaskWorkLog`;
- các hạn chế trong UI có thể chặn việc mở biểu mẫu chỉnh sửa thực thể của người khác ngay cả khi backend cho phép;
- đảm bảo việc chỉnh sửa của quản trị viên không làm thay đổi ẩn chủ sở hữu/người được giao;
- đảm bảo quyền đọc và quyền sửa đổi được kiểm tra riêng biệt.

# Tiêu chí hoàn thành

Quản trị viên có thể mở và lưu các thay đổi đối với công việc, dự án và nhật ký công việc do người dùng hoặc tác nhân khác tạo ra, trong khi người dùng thông thường vẫn không có quyền chỉnh sửa dữ liệu của người khác.

Quản trị viên phải có khả năng chỉnh sửa công việc, dự án và nhật ký công việc của người dùng khác. Hiện tại, các thực thể của người khác không thể chỉnh sửa ngay cả khi có quyền quản trị.

Thêm quyền quản trị để chỉnh sửa công việc, dự án và nhật ký công việc của người khác

Một số tác vụ/workload được dịch không chính xác (thỉnh thoảng xuất hiện bản gốc tiếng Nga thay vì bản dịch; nhân tiện, điều này thường xảy ra khi có một số từ không theo văn phong văn học trong văn bản, chẳng hạn như tên thương hiệu gốc, v.v.).

Vì vậy, chúng ta cần có khả năng bấm nút và nhận được bản dịch đã cập nhật.

Thêm nút dịch ép buộc

## Mục tiêu

Triển khai vi dữ liệu của trang web sao cho các công cụ tìm kiếm có thể hiểu một cách rõ ràng hơn rằng trang web được liên kết với một cá nhân cụ thể, đồng thời liên kết thực thể này với các hồ sơ bên ngoài và các ấn phẩm đã được xác minh.

Bản thân việc đánh dấu không tạo ra thẩm quyền hoặc đảm bảo kết quả nhiều thành phần (rich result) trên Google, nhưng nó giúp mô tả rõ ràng các thực thể và mối quan hệ giữa chúng, đồng thời có thể tạo điều kiện thuận lợi cho việc so khớp các tín hiệu hiện có về cùng một con người.

## Những điểm cần kiểm tra và thiết kế

Hiện tại, trang web đang có đánh dấu `WebSite`. Bạn cần thiết kế một biểu đồ Schema.org hoàn chỉnh, trong đó `Person` xuất hiện như một thực thể riêng biệt, và nếu cần thiết, các thực thể `WebSite`, `WebPage` / `ProfilePage`, bài viết và các thực thể khác sẽ trỏ đến nó thông qua `@id` ổn định.

Kiểm tra riêng xem trang chủ có phù hợp với `ProfilePage` hay không. Theo tài liệu của Google, `ProfilePage` phù hợp khi nội dung chính của trang tập trung vào một cá nhân hoặc tổ chức duy nhất. Nếu trang chủ không mang ý nghĩa là trang hồ sơ cá nhân, thì `Person` vẫn có thể được mô tả như một thực thể riêng biệt trong biểu đồ JSON-LD chung mà không cần biến trang đó thành `ProfilePage`.

## Mục đích của `Person`

`Person` mô tả một con người cụ thể như một thực thể riêng biệt chứ không chỉ là một chuỗi văn bản chứa tên tác giả. Điều này cho phép:

- thiết lập định danh thực thể ổn định thông qua `@id`;
- liên kết tác giả với trang web, các trang, ấn phẩm và các thực thể khác;
- chỉ định tên thay thế / biệt hiệu;
- liên kết con người với các trang bên ngoài định danh rõ ràng cùng một cá nhân đó;
- giảm sự mơ hồ trong trường hợp trùng tên;
- hình thành một biểu đồ JSON-LD nhất quán thay vì một tập hợp các đoạn đánh dấu không liên kết.

## Các trường của `Person` cần xem xét

### Cơ bản

- `@type: "Person"` — loại thực thể.
- `@id` — định danh URI ổn định bên trong biểu đồ, ví dụ: URL của trang web đi kèm với định danh fragment. Cần thiết để tham chiếu lặp lại đến cùng một thực thể từ các nút JSON-LD khác.
- `name` — tên chính của cá nhân. Google khuyến nghị sử dụng tên thật ở đây nếu biết.
- `alternateName` — tên thay thế, bút danh, biệt hiệu hoặc định danh ổn định khác.
- `url` — URL chuẩn (canonical URL) của trang/trang web liên kết với thực thể này.
- `image` — hình ảnh của cá nhân; có thể là URL hoặc `ImageObject`.
- `description` — mô tả ngắn về thực thể.

### Định danh và loại bỏ sự mơ hồ

- `sameAs` — **thuộc tính chính thức của Schema.org**, nhận giá trị kiểu `URL`. Được sử dụng cho các liên kết trỏ đến các trang bên ngoài có nội dung chỉ định rõ ràng về cùng một thực thể. Google đặc biệt khuyến nghị trường này cho các liên kết đến các hồ sơ bên ngoài khác hoặc trang chủ hồ sơ.
- Không nên thêm bất kỳ lượt nhắc đến, danh mục hoặc trang theo chủ đề nào vào `sameAs`. Cần dùng chính xác các trang định danh một cách đáng tin cậy về cùng con người đó: hồ sơ đã xác minh, trang tác giả, Wikidata/Wikipedia và các nguồn tương tự nếu chúng thực sự tồn tại và thuộc về cùng một cá nhân.
- `identifier` — định danh bổ sung, nếu có định danh bên ngoài thực sự ổn định.
- `mainEntityOfPage` — có thể sử dụng khi một trang cụ thể chủ yếu mô tả về cá nhân này.
- `disambiguatingDescription` — chú thích ngắn gọn nếu cần thiết để phân biệt cá nhân đó với những người trùng tên.

### Bối cảnh nghề nghiệp — Chỉ khi dữ liệu thực sự có mặt trên trang web

- `jobTitle` — chức vụ / vai trò chuyên môn.
- `worksFor` — tổ chức nơi cá nhân đó làm việc.
- `affiliation` — tổ chức hoặc cộng đồng mà cá nhân đó có liên kết.
- `knowsAbout` — các lĩnh vực chuyên môn; sử dụng thận trọng và chỉ áp dụng cho thông tin có thể xác thực thực tế.

Không cần điền các trường chỉ để cho đủ bộ Schema.org. Đánh dấu phải phù hợp với nội dung hiển thị trên trang và dữ liệu thực tế.

## Liên kết với `ProfilePage`

Google hỗ trợ dữ liệu có cấu trúc `ProfilePage`. Đối với trang này, đối tượng chính được thiết lập thông qua `mainEntity` có kiểu `Person` hoặc `Organization`.

Nếu trang web có hoặc sẽ có một trang "Giới thiệu" / hồ sơ tác giả riêng biệt, hãy xem xét cấu trúc:

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

Nếu trang chủ chứa nhiều thông tin không chỉ về một cá nhân, đừng sử dụng `ProfilePage` một cách máy móc chỉ vì mục đích SEO.

## `sameAs`: Kết luận dựa trên tài liệu

Trường này tồn tại và là thuộc tính tiêu chuẩn của Schema.org (`Thing.sameAs`). Ý nghĩa của nó: URL của trang **chỉ định rõ ràng về danh tính của cùng một thực thể**.

Trong tài liệu về `ProfilePage`, Google cũng nêu `sameAs` là thuộc tính được khuyến nghị cho `Person` / `Organization`: URL của các hồ sơ bên ngoài khác hoặc trang chủ hồ sơ.

Nói cách khác, việc sử dụng `sameAs` cho các hồ sơ bên ngoài đã được xác minh là hoàn toàn chính xác. Tuy nhiên, cần phải kiểm tra kỹ từng URL trước khi thêm vào và không biến mảng này thành một danh sách chứa tất cả các liên kết bên ngoài nói về cá nhân đó.

## Triển khai

- Chọn một `@id` ổn định cho `Person`.
- Liên kết `WebSite` hiện có với thực thể `Person` ở những nơi có ý nghĩa về mặt ngữ nghĩa.
- Kiểm tra đánh dấu của các trang tác giả/bài viết và nếu có thể, hãy trỏ thuộc tính `author` của chúng về cùng một `@id`.
- Không nhân bản một cá nhân thành các đối tượng `Person` riêng biệt không liên kết trên các trang khác nhau.
- Hình thành `@graph` dạng JSON-LD nếu việc đó giúp đơn giản hóa các mối liên kết giữa `WebSite`, `WebPage`/`ProfilePage`, `Person`, `Article` và các thực thể khác.
- Kiểm tra đánh dấu cuối cùng bằng công cụ Schema Markup Validator và Google Rich Results Test ở những nơi mà loại tương ứng được Google hỗ trợ.
- Đảm bảo rằng các giá trị dữ liệu có cấu trúc khớp với nội dung hiển thị trên trang và các yêu cầu chung của Google đối với dữ liệu có cấu trúc (structured data).

Phát triển và triển khai đánh dấu Schema.org Person chính xác cùng với biểu đồ thực thể trang web liên quan, có tính đến các khuyến nghị của Google Search.

Triển khai vi dữ liệu microdata

# Vấn đề

Khi lưu `content` của Concept, các liên kết nội bộ sẽ được tự động xác thực. Hiện tại, qua hành vi thực tế, trình xác thực chỉ có thể xác nhận chính xác các liên kết đến Concepts.

Do đó, các liên kết nội bộ hợp lệ đến các thực thể fi1osof.ru khác bị xóa bỏ vì bị coi là hỏng.

Ví dụ về các liên kết hợp lệ được mong đợi:

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

Trong quá trình cập nhật Concept HappyBaby, các liên kết Markdown trỏ tới Tasks và Project đã được truyền vào, nhưng sau khi lưu, API trả về phần nội dung mà các liên kết này đã biến mất. Trong khi đó, các liên kết đến Concepts vẫn là kịch bản được hỗ trợ trong cơ chế xác thực hiện tại.

## Cần phải làm gì

Mở rộng cơ chế xác thực liên kết nội bộ trong `content` của Concept để nó hiểu được các route không chỉ của Concepts mà còn của các thực thể nội bộ khác trên trang web.

Tối thiểu phải hỗ trợ:

- `/tasks/[task.id]`
- `/projects/[project.id]`
- Giữ lại các liên kết hiện có tới Concepts mà không gây hồi quy.

Nên làm cho cơ chế xác thực có khả năng mở rộng theo các loại route nội bộ, để khi có các thực thể mới xuất hiện, không cần phải thêm các bản vá tạm thời (workaround) riêng lẻ vào trình xử lý Markdown.

## Tiêu chí hoàn thành

Sau khi lưu Concept, các liên kết hợp lệ đến Tasks và Projects hiện có vẫn giữ nguyên trong nội dung, và các liên kết nội bộ thực sự hỏng vẫn tiếp tục được phát hiện/dọn dẹp theo đúng logic hiện tại.

Sau khi sửa lỗi, cần quay lại Concept HappyBaby và thiết lập lại các liên kết chéo đến các Tasks, Project và Concepts liên quan.

Trình xác thực liên kết trong nội dung Concept hiện chỉ nhận diện chính xác các liên kết đến Concepts và xóa các liên kết đến Tasks, Projects và các thực thể nội bộ khác.

Sửa lỗi xác thực liên kết nội bộ trong Concepts

Bản thân phần này chưa được thiết kế - nó chỉ là một danh sách các concept. Tuy nhiên, cần phải hiển thị nó để lập chỉ mục tốt hơn. Có thể có các concept độc lập không có bất kỳ liên kết đến nào, và chúng ta cần giúp công cụ tìm kiếm có thể dễ dàng tìm thấy những concept đó.

Nhiệm vụ

Thêm liên kết đến phần concept trong chân trang (footer)