fi1osof.ru

Это странно, потому что в целом он работает, но почему-то сломался именно в ловабл-компоненте. Кидает ошибку.

```text
Runtime Error
Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.
```

Tìm hiểu nguyên nhân khiến Markdown bị lỗi trên server

Có rất nhiều trang cũ trong lịch sử. Chúng ta cần tìm lại trang web cũ trong kho lưu trữ và khôi phục nội dung cũ, hoặc xóa sạch chúng. Lựa chọn đầu tiên chắc chắn là ưu tiên hơn.

Cập nhật thông tin trong Yandex.Webmaster

Tính năng này đã có ở backend, chỉ cần thêm vào giao diện

Thêm tính năng tạo nhiệm vụ con

Hiển thị danh sách bộ hẹn giờ trên trang tác vụ

Cập nhật logo và tiến hành tái định vị thương hiệu nhỏ.

Cần thêm .nullable() vào schema, vì hiện tại nếu chưa nhập gì thì khi lưu sẽ xuất hiện lỗi projectId can not be null

Sửa lỗi tạo công việc không có dự án

Hiển thị thông tin dự án trên trang công việc

Việc khởi động bộ đếm thời gian sẽ tự động chuyển tác vụ sang trạng thái Đang thực hiện

Bản nháp:



```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)
  })
}


```

Thêm tiến trình tải lên vào apollo-client

Nhìn chung, tất cả các tính năng đã có sẵn từ haih-agent, chúng ta chỉ cần đưa ra giao diện và tinh chỉnh lại một chút.

Thêm Blog

Cấu hình máy chủ bộ nhớ đệm Varnish

# Mục tiêu

Đưa việc cộng tác với AI lên một tầm cao mới: người dùng xác định **mục tiêu làm việc** bằng ngôn ngữ tự nhiên, ví dụ:

> «Tìm hiểu lý do tại sao dự án X không hoạt động»

Sau đó, tác nhân sẽ tự động thực hiện quá trình từ tìm kiếm dự án và thu thập ngữ cảnh đến kiểm tra giả thuyết và ghi lại kết quả vào fi1osof.ru.

## Kịch bản Mục tiêu

Ví dụ về quy trình làm việc mong muốn:

1. Tìm dự án theo tên hoặc ID.
2. Lấy ngữ cảnh hiện tại của dự án đó.
3. Đọc các công việc liên quan.
4. Đọc các worklog gần đây.
5. Xem các sự kiện/thay đổi gần đây của dự án.
6. Kiểm tra tính khả dụng của trang web/API/dịch vụ, nếu có.
7. Lấy dữ liệu về các lần triển khai, lỗi, nhật ký (log) và trạng thái môi trường gần nhất.
8. Đưa ra một số giả thuyết về nguyên nhân gây ra sự cố.
9. Kiểm tra những giả thuyết có thể kiểm chứng bằng các công cụ có sẵn.
10. Tạo công việc mới hoặc cập nhật công việc hiện có.
11. Ghi lại kết quả điều tra, bằng chứng, liên kết và các bước tiếp theo vào công việc.

Tóm lược:

```text
tìm dự án
→ thu thập các thay đổi gần đây
→ xem các công việc đang mở
→ đọc các worklog gần đây
→ kiểm tra tính khả dụng của trang web/API
→ xem các lỗi và bản triển khai
→ đưa ra giả thuyết
→ kiểm tra các giả thuyết khả thi
→ tạo/cập nhật công việc
→ ghi lại kết quả điều tra
```

# Những gì đã có sẵn

GraphQL API đã cung cấp các thực thể cơ bản cần thiết để bắt đầu quá trình này:

- dự án (projects);
- công việc (tasks);
- nhật ký công việc (task worklogs);
- kỹ năng (skills);
- bộ hẹn giờ/hoạt động (timers/activity);
- `executeSkill`;
- `readWebPage`;
- các truy vấn/thao tác GraphQL khác.

Điều này đã cho phép triển khai một phần chu trình tác nhân mà không cần hệ thống điều phối bên ngoài riêng biệt.

# Những gì còn thiếu

## 1. Ngữ cảnh Kỹ thuật Dự án Được Chuẩn hóa

Cần có khả năng truy xuất rõ ràng các nguồn kỹ thuật liên quan đến dự án:

- kho mã nguồn (repositories);
- các dịch vụ (services);
- môi trường production/staging/dev;
- URL công khai và nội bộ;
- điểm cuối API (API endpoints);
- các lần triển khai (deployments);
- quá trình chạy CI/CD;
- nhật ký (logs);
- lỗi (errors);
- giám sát (monitoring);
- cấu hình (configuration);
- tài liệu (documentation).

Nếu không có điều này, tác nhân có thể phân tích tốt các nhiệm vụ và lịch sử làm việc, nhưng không phải lúc nào cũng có thể xác định được nguyên nhân gốc rễ kỹ thuật của sự cố.

## 2. Mối quan hệ Rõ ràng Giữa các Thực thể

Nên có một đồ thị quan hệ có thể đọc bằng máy, ví dụ:

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

Điều quan trọng là tác nhân không xác định quyền sở hữu đối tượng chỉ dựa trên các tên gọi giống nhau.

## 3. Dòng Hoạt động / Lịch sử Thay đổi (Activity feed)

Cần có một cách thống nhất để trả lời câu hỏi:

> «Điều gì đã thay đổi ngay trước khi sự cố xảy ra?»

Các sự kiện hữu ích:

- thay đổi nhiệm vụ;
- worklog mới;
- bản triển khai (deployment);
- commit/release;
- thay đổi cấu hình;
- health-check thất bại;
- lỗi mới;
- thay đổi DNS/SSL;
- khởi động lại dịch vụ;
- các hành động của người dùng/tác nhân ảnh hưởng đến dự án.

Nên có một truy vấn duy nhất cho các sự kiện gần đây của dự án với bộ lọc theo thời gian và loại sự kiện.

## 4. Công cụ Kiểm tra Giả thuyết An toàn

Tác nhân cần các hành động chẩn đoán chỉ đọc (read-only) hoặc được kiểm soát, chẳng hạn như:

- HTTP health-check;
- đọc trang web;
- kiểm tra API endpoint;
- lấy HTTP status/headers/body fragment;
- tra cứu DNS (DNS lookup);
- kiểm tra chứng chỉ SSL;
- đọc nhật ký (logs);
- kiểm tra trạng thái dịch vụ;
- đọc các bản triển khai gần nhất;
- chạy kiểm tra (test);
- thực thi kỹ năng chẩn đoán.

Một phần trong số này có thể được xây dựng dựa trên `readWebPage` và `executeSkill` hiện có.

## 5. Chính sách Tự chủ

Cần xác định rõ ràng những hành động nào tác nhân có thể tự thực hiện.

### Được phép thực hiện mà không cần xác nhận thêm

- đọc dữ liệu;
- tìm kiếm dự án và các thực thể liên quan;
- thực hiện chẩn đoán chỉ đọc;
- đưa ra giả thuyết;
- đọc nhật ký và hệ thống giám sát;
- tạo worklog chẩn đoán;
- tạo công việc thông thường nếu đó là kết quả tự nhiên của cuộc điều tra;
- bổ sung kết quả chẩn đoán vào công việc.

### Chỉ thực hiện khi có lệnh rõ ràng từ người dùng

- triển khai lên production (production deploy);
- khởi động lại các dịch vụ production;
- thay đổi cấu hình production;
- xóa dữ liệu;
- thay đổi hàng loạt;
- giao dịch tài chính;
- các hành động quản trị;
- thay đổi quyền truy cập;
- bất kỳ hoạt động nào khác có khả năng gây phá huỷ.

# Kỹ năng Cấp cao (High-level Skills)

Không chỉ cần các kỹ năng cấp thấp như «lấy danh sách công việc», mà còn cần các quy trình ở cấp độ mục tiêu làm việc.

Các kỹ năng có thể có:

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

Ví dụ, `investigate_project` có thể xác định một quy trình có thể lặp lại:

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

Kỹ năng nên mô tả một **thuật toán điều tra**, các quy tắc an toàn và định dạng ghi nhận kết quả thay vì chỉ một câu trả lời cụ thể.

# Định dạng Kết quả Điều tra

Nên lưu kết quả vào `Task.content` hoặc worklog bằng định dạng Markdown.

Ví dụ về cấu trúc:

```markdown
# Kết quả điều tra

## Triệu chứng
...

## Những gì đã kiểm tra
- ...
- ...

## Quan sát
- ...

## Giả thuyết
1. ...
2. ...

## Nguyên nhân đã xác nhận
...

## Bằng chứng
- [log / URL / deployment / commit](...)

## Những việc đã làm
- ...

## Hành động tiếp theo
- [ ] ...
- [ ] ...
```

# Nguyên tắc Lưu trữ Công việc Quan trọng

Đối với các công việc trong fi1osof.ru, cần tuân thủ việc phân tách:

- `description` — mô tả ngắn gọn về bản chất của công việc, nghĩa đen là vài câu;
- `content` — toàn bộ nội dung chính, chi tiết, Markdown, liên kết, danh sách kiểm tra (checklist), ví dụ, ngữ cảnh kỹ thuật và kết quả phân tích.

Không sử dụng `description` làm trường nội dung dài chính của công việc.

# Giai đoạn Thực tế Đầu tiên

Trước khi triển khai toàn bộ quy trình làm việc, cần kiểm toán (audit) lược đồ GraphQL hiện tại và các kỹ năng có sẵn:

1. Xác định nguồn dữ liệu nào trong số các nguồn được liệt kê đã tồn tại.
2. Kiểm tra các mối quan hệ hiện có giữa `Project`, `Task`, `TaskWorkLog`, các kỹ năng và các thực thể khác.
3. Tìm các thao tác có sẵn để chẩn đoán web/API.
4. Xác định xem các mô hình deployments, logs, environments, repositories, events/activity đã có sẵn chưa.
5. Thực hiện phân tích khoảng trống (gap analysis): **những gì có thể làm ngay bây giờ / những gì còn thiếu trong API / những gì còn thiếu trong các kỹ năng**.
6. Dựa vào đó, thiết kế quy trình `investigate_project` tối thiểu.

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

Một nhiệm vụ được coi là đã hoàn thành khi một lệnh dạng:

> «Tìm hiểu tại sao haih.net hôm nay không hoạt động»

có thể được xử lý bởi tác nhân như một mục tiêu làm việc, thay vì một loạt lệnh GraphQL thủ công, và kết quả là tác nhân:

- tự động thu thập ngữ cảnh có liên quan;
- cho biết chính xác những gì nó đã kiểm tra;
- phân biệt rõ ràng giữa sự thật và giả thuyết;
- kiểm tra các giả thuyết khả thi;
- không thực hiện các hành động nguy hiểm mà không có sự cho phép;
- lưu tóm tắt kết quả điều tra vào fi1osof.ru.

Thiết kế và triển khai một quy trình làm việc an toàn, trong đó AI tự động thu thập ngữ cảnh dự án, kiểm tra các giả thuyết và ghi lại kết quả điều tra dựa trên một mục tiêu duy nhất.

Chế độ Tác nhân Điều tra Sự cố Dự án

# Vấn đề

Hiện tại, vai trò của những người tham gia công việc chưa được hiển thị đủ rõ ràng trong giao diện công việc. Người dùng cần có thể nắm bắt ngay lập tức:

- ai là người giao việc;
- ai chịu trách nhiệm thực hiện công việc đó.

Điều này đặc biệt quan trọng trong việc cộng tác giữa con người và các tác nhân AI, cũng như trong các nhóm mà người giao việc và người thực hiện thường khác nhau.

# Cần làm gì

Thêm hiển thị của hai vai trò riêng biệt:

- **Người tạo** — người dùng/tác nhân đã tạo hoặc giao công việc;
- **Người thực hiện** — người dùng/tác nhân được giao công việc.

# Hiển thị ở đâu

## Danh sách công việc

Mỗi dòng/thẻ trong danh sách cần hiển thị rõ:

- người tạo;
- người thực hiện.

Giao diện hiển thị phải nhỏ gọn và không làm quá tải danh sách.

## Thẻ công việc

Trong thẻ chi tiết công việc, cả hai vai trò phải được hiển thị rõ ràng và tách biệt, kèm theo các nhãn dễ hiểu.

# Cần kiểm tra

- những trường GraphQL nào đã chứa creator / author / owner / assignee;
- có sự khác biệt nào giữa người tạo thực tế của công việc và người giao việc không;
- người dùng và tác nhân AI có được hiển thị chính xác không;
- điều gì xảy ra nếu chưa gán người thực hiện;
- điều gì xảy ra nếu người tạo và người thực hiện là cùng một người dùng;
- đảm bảo các vai trò không bị gộp chung vào một trường giao diện.

# Hành vi mong đợi

Khi mở danh sách hoặc thẻ công việc, người dùng có thể hiểu ngay mà không cần thêm thao tác nào:

> ai đã giao công việc và ai chịu trách nhiệm cho công việc đó.

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

- hiển thị cả hai vai trò trong danh sách công việc;
- hiển thị cả hai vai trò trong thẻ công việc;
- người tạo và người thực hiện được hiển thị như hai thực thể riêng biệt;
- hỗ trợ chính xác cả người dùng thông thường lẫn tác nhân AI;
- trường người thực hiện để trống được hiển thị một cách dễ hiểu, ví dụ: "Chưa phân công".

Giao diện công việc cần hiển thị rõ ràng cả người tạo và người thực hiện ở cả danh sách công việc lẫn thẻ chi tiết công việc.

Hiển thị người tạo và người thực hiện trong danh sách và thẻ công việc

# Bối cảnh

Nguồn chân lý kiến trúc: [Hệ thống URI thân thiện với con người trong haih-agent duy trì sự ổn định của địa chỉ và tín hiệu SEO](/concepts/sistema-chelovekoponyatnyh-uri-v-haih-agent-sohranyaet-stabilnost-adresov-i-seo-signaly).

Trên fi1osof.ru, các Concept đang trở thành các trang SEO/GEO công khai chính. Các URL thân thiện (ChPU) phải tương ứng một cách có hệ thống với tên/nội dung hiện tại của Concept và không phụ thuộc vào việc người dùng có nhớ cập nhật thủ công URI hay không.

## Cần làm gì

### 1. Nút cập nhật chuyển tự bắt buộc

Trong giao diện chỉnh sửa Concept, thêm một hành động rõ ràng, chẳng hạn như "Cập nhật URI / chuyển tự".

Thao tác này cần:

- tính toán lại URI thân thiện theo quy tắc slugify/transliteration hiện hành;
- hiển thị/áp dụng URI mới;
- sử dụng cơ chế thay đổi URI chung để địa chỉ cũ được chuyển hướng thông qua 301;
- xử lý chính xác xung đột (collision) của URI mới.

Điều này là cần thiết đối với các Concept đã tồn tại và các trường hợp cần xây dựng lại một cách rõ ràng một slug cũ hoặc không tốt.

### 2. Chuyển tự tự động khi tạo/cập nhật (create/update)

Khi tạo Concept, URI phải được tự động tạo từ `name` hiện tại theo logic ChPU chung.

Khi cập nhật Concept, cần tự động cập nhật chuyển tự/slug trong các trường hợp tên hoặc trường khác mà URI phụ thuộc vào đã thay đổi.

Không sao chép thuật toán slugify ở frontend: sử dụng hàm phía máy chủ (server) chung của haih-agent.

Khi thay đổi URI, bắt buộc phải sử dụng cơ chế hiện có `old URI → 301 → new URI`.

Điều quan trọng là không tạo ra cơ chế xáo trộn vô tận: nếu URI được tính toán trùng khớp với URI hiện tại, không thay đổi gì cả.

## Ý nghĩa SEO

Tên của Concept là một trong những tín hiệu ngữ nghĩa chính của trang. URI phải phản ánh chủ đề hiện tại để:

- các từ khóa xuất hiện trong URL;
- các Concept mới được tạo ngay lập tức với URL thân thiện thay vì CUID;
- một Concept được đổi tên không bị kẹt mãi với slug vô nghĩa cũ;
- canonical URL và các liên kết nội bộ duy trì sự đồng bộ;
- các địa chỉ cũ giữ lại các tín hiệu tích lũy thông qua chuyển hướng 301.

## Tiêu chí nghiệm thu

- [ ] Trong trình chỉnh sửa Concept có nút tính toán lại URI/chuyển tự bắt buộc.
- [ ] Khi tạo Concept, URL thân thiện được tạo tự động.
- [ ] Khi thay đổi tên (name), URI sẽ tự động được đưa về slug hiện hành theo quy tắc thống nhất.
- [ ] Sử dụng logic slugify/transliteration chung ở phía máy chủ của haih-agent.
- [ ] Khi thay đổi URI, hệ thống tự động tạo/sử dụng chuyển hướng 301 từ địa chỉ cũ.
- [ ] Lưu lại lần nữa mà không thay đổi slug đích thì sẽ không làm thay đổi URI.
- [ ] Xung đột của URI mới được xử lý một cách an toàn và rõ ràng.
- [ ] Đã thêm các bài kiểm tra hồi quy (regression tests) cho các thao tác tạo, đổi tên, làm mới bắt buộc, giữ nguyên slug và xung đột.

Thêm nút cập nhật thủ công chuyển tự của Concept và tự động duy trì URL thân thiện (ChPU) khi tạo/cập nhật nội dung.

Thêm tính năng cập nhật chuyển tự URI bắt buộc và tự động cho Concept

# Mục tiêu

Thêm một nhóm Concepts công khai riêng vào fi1osof.ru để làm nhật ký công việc có nội dung thường xuyên và liên kết nó với trang chính.

## Các loại Concepts

Thỏa thuận cơ bản:

- bài viết thông thường: `article:default`;
- cần một loại/phụ loại riêng cho báo cáo tuần — xác định tên chính xác khi triển khai;
- nếu cần thiết, hãy chuẩn bị khả năng mở rộng họ `article:*` mà không tạo ra quá nhiều sự phân loại trước.

## Bài viết hàng ngày

Mỗi ngày hình thành một báo cáo có nội dung cho ngày hôm trước.

Đây không phải là một danh sách hẹn giờ máy móc. Bài viết phải tổng hợp thành một tài liệu gắn kết:

- những gì đã thảo luận;
- những gì thực sự được làm;
- nhiệm vụ và dự án nào nằm trong tâm điểm;
- những vấn đề nào đã được phát hiện;
- những quyết định nào đã được đưa ra;
- những kết luận nào đã xuất hiện;
- những câu hỏi nào vẫn còn bỏ ngỏ;
- điều gì cần chú ý tiếp theo.

Dữ liệu nguồn có thể lấy từ Timers, Tasks, WorkLogs, Concepts, MindLogs/các cuộc thảo luận và các nguồn ngữ cảnh khác có sẵn.

## Báo cáo tuần

Cần có một báo cáo riêng cho mỗi tuần. Nó không phải là sự chắp vá của bảy bài viết hàng ngày, mà là mức độ tổng quát hóa cao hơn:

- các hướng chính trong tuần;
- thời gian thực tế đã dành cho việc gì;
- những gì đã thay đổi trong các dự án;
- các kết quả quan trọng nhất;
- các vấn đề hệ thống được phát hiện;
- kết luận và thay đổi ưu tiên.

Xác định định dạng chính xác và loại Concept riêng.

## Phần động của trang chính

Hiển thị 3 mục nhật ký mới nhất trên trang chính:

- hiển thị tiêu đề;
- hiển thị description;
- bản thân bài viết có thể có dung lượng lớn hơn đáng kể;
- thêm liên kết **"Tất cả log"** đến danh sách đầy đủ.

Phần này phải được hình thành động và cho thấy tác giả thực sự đang làm gì lúc này.

## Phần tĩnh của trang chính

Ngoài feed động, trang chính vẫn giữ lại phần tĩnh được lưu trữ trực tiếp trong `content` của Concept gốc `/`.

Nhiệm vụ của nó là thiết lập ngữ cảnh cố định và các tuyến đường ngữ nghĩa chính: các dự án trực tiếp phức tạp, việc ứng dụng AI thực tế, legacy/cứu trợ dự án, kinh nghiệm tư vấn, các hướng đi hiện tại mạnh mẽ.

Chưa chốt tỷ lệ chính xác giữa phần tĩnh và phần động. Điều này cần được suy nghĩ kỹ lưỡng sau khi các bài viết dạng article thực tế xuất hiện.

## Nguyên tắc quan trọng

Nhật ký được tạo ra không phải như một worklog nội bộ cho tác giả, mà là một lớp nội dung công khai cho khách hàng tiềm năng. Ngay cả một bài viết hàng ngày cũng phải thú vị đối với độc giả bên ngoài và thông qua các sự kiện thực tế, thể hiện năng lực, vấn đề, giải pháp và dòng suy nghĩ.

Việc liên kết chéo bên trong các bài viết và với trang chính hiện có thể đóng vai trò là CTA chính.

Thiết kế article:* Concepts, báo cáo công việc hàng ngày và hàng tuần, cùng hiển thị các bài viết gần đây trên trang chính.

Phát triển Concepts dạng blog và feed động cho trang chính

Cần phải triển khai các URI ổn định, dễ đọc cho ba loại thực thể trên fi1osof.ru:

- dự án (projects);
- công việc (tasks);
- nhật ký công việc (worklogs).

Hiện tại, các liên kết đến các thực thể này đang phụ thuộc vào ID. Trường `uri` riêng biệt với URL thân thiện và tính năng kiểm tra sự tồn tại của liên kết ở phía máy chủ đã được sử dụng cho các khái niệm; một nguyên tắc tương tự cũng cần thiết cho các thực thể làm việc.

Các yêu cầu tối thiểu:

1. Thêm trường `uri` riêng biệt hoặc slug/route ổn định tương đương cho Project, Task và Worklog.
2. Tạo URL thân thiện từ tên/tiêu đề của thực thể với đảm bảo tính duy nhất.
3. Không làm hỏng các tuyến đường dựa trên ID hiện có: các liên kết cũ phải tiếp tục hoạt động hoặc chuyển hướng chính xác đến URI chính tắc (canonical URI).
4. Sử dụng URL thân thiện làm đường dẫn chính tắc trong các liên kết Markdown nội bộ và giao diện.
5. Xử lý việc đổi tên thực thể: URI không được tự động làm hỏng các liên kết đã tồn tại; cần có một chiến lược rõ ràng về tính ổn định hoặc chuyển hướng.
6. Thêm tính năng xác thực phía máy chủ cho các liên kết nội bộ tương tự như các khái niệm, để các tuyến đường không tồn tại không bị lưu thành liên kết hợp lệ.
7. Sau khi triển khai, cập nhật các quy tắc/kỹ năng làm việc với fi1osof.ru: trước khi tạo liên kết nội bộ, tác nhân (agent) phải đọc `uri` thực tế của thực thể thay vì tự xây dựng đường dẫn từ ID hoặc tên.

Mục tiêu là đưa các dự án, công việc, khái niệm và nhật ký công việc về một hệ thống liên kết chéo nội bộ ổn định thống nhất.

Thêm URI dễ đọc cho con người đối với các thực thể làm việc chính của fi1osof.ru theo mô hình tương tự như các khái niệm (concepts).

Tạo URL thân thiện với SEO (ЧПУ) cho dự án, công việc và nhật ký công việc (worklogs)

## Cần thay đổi gì

Hiện tại, các worklog trong thẻ task đang được hiển thị theo thứ tự **từ mới đến cũ**. Điều này gây bất tiện khi đọc lịch sử công việc trong cùng một task: chuỗi sự kiện phải được đọc từ dưới lên trên.

Chúng ta cần thay đổi hành vi của khối worklog:

- mặc định hiển thị worklog **từ cũ đến mới** để lịch sử được đọc theo trình tự thời gian từ trên xuống dưới;
- thêm nút chuyển đổi sắp xếp vào chính khối worklog;
- các tùy chọn chuyển đổi: **"Cũ trước"** và **"Mới trước"**;
- thứ tự đã chọn phải được áp dụng ngay lập tức cho danh sách mà không làm thay đổi bản thân dữ liệu worklog.

## Kết quả mong đợi

Khi mở một task, lịch sử worklog được đọc một cách tự nhiên — từ cái đầu tiên đến cái cuối cùng. Nếu cần, người dùng có thể chuyển đổi thứ tự và xem các mục mới nhất trước.

Đặt sắp xếp worklog theo thứ tự thời gian làm mặc định và thêm nút chuyển đổi thứ tự hiển thị.

Thay đổi cách sắp xếp worklog trong task

## Bối cảnh

Khi làm việc trong Codex cục bộ theo gói đăng ký, người ta thường quan sát thấy vấn đề về độ ổn định của các đoạn chat dài, đặc biệt là khi agent bắt đầu làm việc tích cực với hình ảnh và bản mẫu (layout).

Quan sát thực tế:

> «Codex cũng được "vibe-code" sẵn. Các đoạn chat liên tục bị đơ. Nếu nó đã đứng hình thì là đứng luôn. Không có lỗi lầm gì cả. Chỉ là chờ đợi lâu, rồi kết nối lại. Bắt đầu chat mới — và nó lại chạy bình thường. Cho đến khi lại đơ tiếp».

Và một ý kiến khác:

> «Ngay khi bắt đầu làm việc với hình ảnh là nó đơ rất nhanh».

Ngoài việc bị đơ, việc tạo/xử lý hình ảnh bên trong phiên AI làm tiêu tốn đáng kể ngữ cảnh/token và có thể khiến công việc thiết kế mang tính lặp đi lặp lại trở nên tốn kém và kém ổn định.

## Giả thuyết

Tách biệt phần suy luận/thị giác (reasoning/vision) và việc tạo ảnh trực tiếp.

Để AI agent chịu trách nhiệm về:

- Hiểu nhiệm vụ và các yêu cầu về UI/visual;
- Chuẩn bị và tinh chỉnh prompt;
- Lựa chọn tham số/phương án tạo ảnh;
- Phân tích hình ảnh thu được thông qua thị giác (vision);
- So sánh với các yêu cầu/tham chiếu (reference);
- Hình thành vòng lặp tiếp theo;
- Quyết định xem kết quả đã đủ tốt chưa.

Việc tạo ảnh nặng thực hiện cục bộ thông qua **ComfyUI** và các mô hình/workflow tạo ảnh cục bộ phù hợp.

Chu trình dự kiến:

```text
requirements / UI hiện tại
        ↓
AI agent
        ↓
prompt + tham số tạo ảnh
        ↓
ComfyUI cục bộ
        ↓
(các) hình ảnh
        ↓
AI vision review
        ↓
chỉnh sửa prompt / tham số
        ↺
```

Nghĩa là sử dụng mô hình đa phương thức đắt đỏ chủ yếu ở nơi nó hữu ích nhất: **cho việc lập nhiệm vụ, suy luận và kiểm tra kết quả**, còn việc tạo hàng loạt pixel thì đưa ra ngoài một pipeline cục bộ chuyên biệt.

## Cần nghiên cứu gì

1. Thiết lập một ComfyUI cục bộ có khả năng tái tạo.
2. Lựa chọn tập hợp tối thiểu các mô hình/workflow cho UI mockup, hình minh họa và các tác vụ phát triển trực quan điển hình khác.
3. Xác định giao diện lập trình đơn giản để coding agent có thể chạy workflow và nhận kết quả mà không cần thao tác thủ công trong UI của ComfyUI.
4. Kiểm tra xem agent có thể tự thực hiện chu trình `prompt → generate → inspect → adjust → generate` hay không.
5. Kiểm tra việc làm việc với nhiều ứng viên (candidate) và chọn ra kết quả tốt nhất.
6. Xác định dữ liệu trung gian nào thực sự cần trả về ngữ cảnh AI, và dữ liệu nào có thể lưu cục bộ để tránh làm phình to phiên làm việc.
7. Nghiên cứu xem có thể cô lập workflow tạo ảnh khỏi đoạn chat lập trình chính hay không, để các vòng lặp trực quan không làm giảm độ ổn định của ngữ cảnh chính.
8. Ghi nhận các lỗi thực tế (failure modes): ComfyUI bị đơ, thiếu VRAM/RAM, tác vụ tạo ảnh kéo dài, prompt không chính xác, sự cố vision-review, tích tụ file, v.v.
9. So sánh với workflow hiện tại.

Thực hiện một số tác vụ trực quan giống nhau bằng hai cách:

### A. Phương pháp hiện tại

AI/Codex/ChatGPT tự làm việc với việc tạo ảnh bên trong phiên đa phương thức của chính nó.

### B. Pipeline cục bộ

AI tạo ra nhiệm vụ và kiểm tra kết quả, còn việc tạo ảnh do ComfyUI thực hiện.

Đối với mỗi kịch bản, cần ghi nhận:

- Thời gian thực tế (wall-clock time) để đạt được kết quả chấp nhận được;
- Số lượng vòng lặp;
- Mức tiêu thụ token/ngữ cảnh (trong giới hạn có thể đo lường);
- Độ ổn định của phiên AI chính;
- Số lần đơ/kết nối lại/khởi động lại;
- Chất lượng kết quả cuối cùng;
- Khối lượng sự tham gia thủ công của con người;
- Chi phí GPU/VRAM/RAM cục bộ;
- Khả năng tự chẩn đoán lỗi tạo ảnh của agent.

## Tiêu chí kết quả

Có được một pipeline thử nghiệm hoạt động được, trong đó coding agent có thể gọi ComfyUI cục bộ, nhận hình ảnh, tự kiểm tra trực quan và khởi chạy vòng lặp tiếp theo nếu cần.

Sau một số tác vụ thực tế, cần trả lời các câu hỏi:

- Điều này có làm giảm mức tiêu thụ ngữ cảnh/token của AI không?
- Đoạn chat lập trình có trở nên ổn định hơn không?
- Toàn bộ chu trình cho đến khi đạt kết quả chấp nhận được bị chậm đi hay nhanh lên?
- Chất lượng của các mô hình cục bộ có đủ cho công việc sản phẩm thực tế không?
- Những loại tác vụ trực quan nào nên thực hiện cục bộ, loại nào nên để lại cho mô hình đa phương thức/tạo ảnh bên ngoài?
- Có nên đóng gói pipeline này thành một công cụ/skill vĩnh viễn cho các AI agent không?

## Hạn chế quan trọng

Không coi việc tiêu thụ token hoặc tạo ảnh ở phía mô hình là nguyên nhân đã được chứng minh chắc chắn gây ra hiện tượng đơ của Codex. Đây là một mối tương quan quan sát được, mà thí nghiệm này phải giúp tách biệt khỏi các nguyên nhân khác. Mục tiêu là kiểm tra hiệu quả thực tế của một workflow thay thế, chứ không phải giải thích trước nguyên nhân bên trong gây đơ của Codex.

Kiểm tra xem có thể chuyển việc tạo ảnh từ Codex/ChatGPT sang ComfyUI cục bộ hay không, để lại phần lập nhiệm vụ, prompt và kiểm tra bằng thị giác (vision) cho agent, nhằm giảm tiêu thụ token và hiện tượng đơ khi làm việc với hình ảnh.