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

На странице задачи вывести список таймеров

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

Cần kiểm tra kỹ hơn Google và Yandex Webmaster. Rất có thể hàng đợi chỉ đơn giản là bị tắc nghẽn bởi các trang cũ đã lâu không còn tồn tại trên trang web. Nghĩa là, chúng ta cần thông báo cho họ rằng không cần tìm kiếm các trang đó nữa, mà cần lập chỉ mục các trang mới.&#x20;

Tìm hiểu nguyên nhân trang web được lập chỉ mục kém

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.

Nhiệm vụ

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