docs: record PR #180-#182, add P-007/P-008, open TASK-20260910-006

CHANGELOG.md

@@ -16,6 +16,9 @@ Open problems and known blockers are tracked separately in
 - **PR #174** — deliverables: added `deliverables/pm-backend/` — a FastAPI app with provider-neutral billing (Stripe / Chargebee / Paddle adapters behind one interface), CSV reconciliation, and sandbox integration tests (58 passed, 15 skipped).
 - **PR #178** — deliverables: added `deliverables/agent-core/` — a runnable, tested FastAPI backend for provider-agnostic agent tasks (async `httpx` client, bounded retry + polling, Supabase task store with RLS, `schema.sql`). Ported from the single-file "Dola Core" draft and renamed Dola → Agent. Fixes that made it actually start: lazy settings (import no longer needs credentials), async I/O instead of blocking `requests`, retry that preserves the original error, bounded polling, and a real persistence layer. 25 offline tests.
 - **PR #179** — tasks: added `TASK-20260910-005` recording the five things PR #178 could not prove (placeholder base URL, unverified response field names, unapplied Supabase schema, untested RLS, never-run CI example). Also fixed a tracker bug: `TASK_TEMPLATE.md`'s `status:` comment was copied verbatim by `cmd_new`, breaking three tests that read the template.
+- **PR #180** — docs: recorded PR #178 and #179 in this changelog.
+- **PR #181** — docs: added `PROBLEMS.md` as the companion to this file, tracking open issues and blockers in the same date sections.
+- **PR #182** — tasks: closed `TASK-20260910-005` (→ `done/`) with its Completion summary citing both `CHANGELOG.md` and `PROBLEMS.md` P-004. Also corrected two stale records: `TASK-20260910-004` was renamed to match its id and its validation table filled with measured numbers, and `TASK-20260910-003` gained a re-check showing its fix is still not on remote.
 
 ### Fixed
 - **Issue #63 closed** — the `pure-agent-dev` implementation merged to `main` via PR #169 (squash `590b8615`); the issue was closed by the PR's `Closes #63` reference. No `.github/workflows/` files were touched, so the merge was not blocked by the App's `workflows` restriction.

PROBLEMS.md

@@ -138,6 +138,47 @@ generated content — can reappear if the template is annotated again.
 
 ---
 
+### P-007 — `new-crystalcastle` CI: five workflows read a `requirements.txt` that does not exist at the root — OPEN
+
+**Owner:** `TASK-20260910-006`
+
+Five workflows in `new-crystalcastle` run `pip install -r requirements.txt`, but
+the repository has no root `requirements.txt` — the only one is
+`scripts/errorlog-generator/requirements.txt`. Every job fails immediately:
+
+```
+ERROR: Could not open requirements file:
+[Errno 2] No such file or directory: 'requirements.txt'
+##[error]Process completed with exit code 1.
+```
+
+Affected workflows: `FastAPI_CI.yaml`, `Python-CI.yml`,
+`crystalcastle-coderabbit-test.yml`, `errorlog-generator.yml`, `test.yml`.
+
+**Evidence:** failure log for run `34471137096` on `main` (2026-09-10);
+`find . -name 'requirements*.txt'` returns only the `scripts/` path.
+
+**Note:** this is a **separate cause** from the bad-SHA problem in
+`TASK-20260910-003`. Fixing the codeql SHAs alone will not turn this repo's CI
+green.
+
+**Fix:** either add a root `requirements.txt`, or point each workflow at the
+real path (or at `pyproject.toml`). Which one is correct depends on the intended
+project layout — needs the owner's decision, not a guess.
+
+---
+
+### P-008 — `TASK-20260910-004` was stored in a file named `example-task.md` — RESOLVED
+
+Fixed in PR #182. The tracker's example file had been overwritten in place with
+a real task while keeping the placeholder filename, so the id in the
+front-matter (`TASK-20260910-004`) did not match the path. Renamed to
+`TASK-20260910-004-repair-github-actions-workflows.md`. Recorded because the
+same mistake — reusing a template file for live content — will hide a task from
+anyone browsing by filename.
+
+---
+
 ## How to add an entry
 
 1. Put it under the date section matching its changelog counterpart.

new.inprogress.done/new/TASK-20260910-006-ncc-ci-workflows-requirements-txt.md

@@ -0,0 +1,76 @@
+---
+id: TASK-20260910-006
+title: ncc CI — workflows อ้าง requirements.txt ที่ไม่มีอยู่
+status: new
+priority: high
+created: 2026-09-10
+updated: 2026-09-10
+owner: fig-agent
+repo: ZyntroAI/new-crystalcastle
+issue:
+prs: []
+blocked_by: ต้องให้เจ้าของ repo ตัดสิน layout (เพิ่ม requirements.txt ที่ root หรือชี้ path จริง)
+tokens: 0
+---
+
+# TASK-20260910-006 — ncc CI อ้าง `requirements.txt` ที่ไม่มีอยู่
+
+## Goal
+
+ทำให้ CI ของ `new-crystalcastle` เดินต่อได้หลังขั้นติดตั้ง dependency — ตอนนี้
+ล้มทันทีที่ `pip install` เพราะหาไฟล์ไม่เจอ ไม่ใช่เพราะเทสต์พัง
+
+## Scope
+
+- ตรวจ workflow ทั้ง 5 ที่อ้าง `requirements.txt` ที่ root
+- ตัดสินว่า layout ที่ถูกคืออะไร แล้วแก้ให้ตรง (เพิ่มไฟล์ หรือชี้ path จริง)
+- ยืนยันด้วยการรัน CI จริง
+
+## Out of scope
+
+- แก้ SHA ใน `codeql.yml` — เป็นเรื่องของ `TASK-20260910-003` (คนละสาเหตุ)
+- เปลี่ยนชุด dependency หรือ pin version ให้ใหม่
+
+## Steps
+
+- [x] ยืนยันสาเหตุจาก log จริง (ไม่ใช่สันนิษฐาน)
+- [ ] หาว่า layout ที่ตั้งใจคืออะไร (root package หรือ `scripts/` แยกส่วน)
+- [ ] แก้ workflow 5 ตัวให้ชี้ path ที่ถูก
+- [ ] push + เปิด PR
+- [ ] ยืนยันว่า job ผ่านขั้น install แล้ว
+
+## Acceptance criteria
+
+- [ ] `pip install -r …` ใน workflow ทั้ง 5 หาไฟล์เจอ
+- [ ] job เดินผ่านขั้นติดตั้ง dependency
+- [ ] ไม่มี workflow ใดเปลี่ยนพฤติกรรมเกินกว่าการชี้ path
+
+## Dependencies / blockers
+
+**Blocked.** ต้องรู้ว่าเจ้าของตั้งใจให้ layout เป็นแบบไหน — เติม
+`requirements.txt` ที่ root กับชี้ไป `scripts/errorlog-generator/requirements.txt`
+ให้ผลต่างกันคนละแบบ (`test.yml` กับ `errorlog-generator.yml` อาจตั้งใจใช้ไฟล์
+คนละตัว) การเดาแล้วแก้แทนจะทำให้ CI ผ่านแต่ผิดความตั้งใจ
+
+## Files changed
+
+| File | Change |
+| --- | --- |
+| ยังไม่แตะ — รอตัดสิน layout | |
+
+## Validation
+
+| Command | Result |
+| --- | --- |
+| `find . -name 'requirements*.txt'` | เจอแค่ `scripts/errorlog-generator/requirements.txt` |
+| `grep -rln requirements.txt .github/workflows/` | **5 ไฟล์** |
+| `gh run view 34471137096 --log-failed` | `Could not open requirements file: No such file or directory: 'requirements.txt'` |
+
+## Notes
+
+สาเหตุนี้ **แยกจาก** ปัญหา SHA ปลอมใน `TASK-20260910-003` — ต่อให้ pin SHA
+ถูกต้อง CI ก็ยังแดงด้วยเหตุนี้ บันทึกไว้ที่ `PROBLEMS.md` **P-007**
+
+## Completion summary
+
+*ยังไม่ปิดงาน.*