Move all work tracking from the repo into Forgejo issues and milestones #54

Closed
opened 2026-07-28 05:01:27 +00:00 by claude-bot · 1 comment

Context

Work was tracked in-repo via docs/circa-phase1-plan.md and docs/circa-phase1-backlog.md.
Those documents are static, drift from reality as work completes, and cannot record
discussion or state. Tracking moves to Forgejo issues and milestones; the repo keeps only
design and specification documents.

What was done

Milestones — semantic versions mapped to the phase roadmap in docs/circa-spec.md section 14:

Milestone Scope
v0.2.0 Phase 1 completion — worker runtime, AI/OCR backends, test suite, CI
v0.3.0 Phase 2 — constraint propagation & collaboration
v0.4.0 Phase 3 — export & organization
v0.5.0 Phase 4 — pluggable backends & polish
v1.0.0 Initial feature set complete

Issues — 52 created (#2–#53), each with scope, implementation notes, done-when criteria,
and references to the relevant spec sections and source files.

Labels — added backend, frontend, worker, testing, infra, ai, security, docs.

Repo changes — deleted both tracking docs; AGENTS.md and README.md now point at Forgejo
and record that backlog/plan/TODO docs should not be added to the repo; refreshed the stale
backend/alembic/versions/README.md.

Notes on scope

The v0.1.0 backlog items were not recreated as closed issues — that work is already
recorded in CHANGELOG.md and git history, and importing ~50 pre-closed tickets would add
noise without adding a usable trail.

Three gaps surfaced while auditing the backlog against the code, and became issues rather
than being folded silently into the migration:

  • backend/app/workers/ contains only __init__.py, so AI and OCR rerun jobs enqueue but
    never execute (#2, #3, #4)
  • there are no automated tests in the repo at all, despite pytest being configured in
    pyproject.toml (#5–#12), and no CI (#13)
  • CIRCA_SECRET_KEY defaults to change-me-in-production and signs session cookies, with
    nothing preventing that default from reaching a deployment (#14)

The design and specification docs in docs/ were left in place — they are reference
material, not work tracking.

## Context Work was tracked in-repo via `docs/circa-phase1-plan.md` and `docs/circa-phase1-backlog.md`. Those documents are static, drift from reality as work completes, and cannot record discussion or state. Tracking moves to Forgejo issues and milestones; the repo keeps only design and specification documents. ## What was done **Milestones** — semantic versions mapped to the phase roadmap in `docs/circa-spec.md` section 14: | Milestone | Scope | |---|---| | `v0.2.0` | Phase 1 completion — worker runtime, AI/OCR backends, test suite, CI | | `v0.3.0` | Phase 2 — constraint propagation & collaboration | | `v0.4.0` | Phase 3 — export & organization | | `v0.5.0` | Phase 4 — pluggable backends & polish | | `v1.0.0` | Initial feature set complete | **Issues** — 52 created (#2–#53), each with scope, implementation notes, done-when criteria, and references to the relevant spec sections and source files. **Labels** — added `backend`, `frontend`, `worker`, `testing`, `infra`, `ai`, `security`, `docs`. **Repo changes** — deleted both tracking docs; `AGENTS.md` and `README.md` now point at Forgejo and record that backlog/plan/TODO docs should not be added to the repo; refreshed the stale `backend/alembic/versions/README.md`. ## Notes on scope The v0.1.0 backlog items were **not** recreated as closed issues — that work is already recorded in `CHANGELOG.md` and git history, and importing ~50 pre-closed tickets would add noise without adding a usable trail. Three gaps surfaced while auditing the backlog against the code, and became issues rather than being folded silently into the migration: - `backend/app/workers/` contains only `__init__.py`, so AI and OCR rerun jobs enqueue but never execute (#2, #3, #4) - there are no automated tests in the repo at all, despite pytest being configured in `pyproject.toml` (#5–#12), and no CI (#13) - `CIRCA_SECRET_KEY` defaults to `change-me-in-production` and signs session cookies, with nothing preventing that default from reaching a deployment (#14) The design and specification docs in `docs/` were left in place — they are reference material, not work tracking.
Author

Done in a2d48ff.

Repo side: deleted both tracking docs (438 + 506 lines, recoverable from git history), added a Work Tracking section to AGENTS.md with the milestone table and the instruction to read an issue's full comment thread before picking it up, replaced the Docs list entry in README.md with links to issues and milestones, and refreshed backend/alembic/versions/README.md.

README.md's Status section now names the v0.2.0 gaps explicitly rather than claiming Phase 1 is complete — the worker, the AI/OCR backends, and the test suite are all outstanding.

CHANGELOG.md and the design/spec docs in docs/ stayed — the changelog is a release record required by AGENTS.md, and the specs are reference material rather than work tracking.

Done in a2d48ff. Repo side: deleted both tracking docs (438 + 506 lines, recoverable from git history), added a **Work Tracking** section to `AGENTS.md` with the milestone table and the instruction to read an issue's full comment thread before picking it up, replaced the Docs list entry in `README.md` with links to issues and milestones, and refreshed `backend/alembic/versions/README.md`. `README.md`'s Status section now names the v0.2.0 gaps explicitly rather than claiming Phase 1 is complete — the worker, the AI/OCR backends, and the test suite are all outstanding. `CHANGELOG.md` and the design/spec docs in `docs/` stayed — the changelog is a release record required by `AGENTS.md`, and the specs are reference material rather than work tracking.
Sign in to join this conversation.
No description provided.