Review — PR #29: bootstrap repo (v0.1.0)

Manual gates (CI doesn't exist yet, per #9 deferral). Verified the four files on the branch:

• pyproject.toml — clean PEP 639 license format, [tool.uv] package = false, two seed deps with reasonable floors.
• LICENSE — MIT, copyright 2026, your name. Standard.
• README.md — 2-sentence stub linking issues + project board. Honest about status.
• uv.lock — 11 packages (10 transitive + the project itself), resolved against CPython 3.14.

.gitignore exists (~4.6 KB GitHub Python template) — checked it still has the unanchored lib/, build/, dist/, eggs/, sdist/, parts/, var/, wheels/ patterns that bit the previous project. You called this out as deferred to #5 with feedback_gitignore_anchor_lib cited. Good explicit deferral.

Discipline carrying over from the previous project — caught and named

You front-loaded everything I'd have flagged:

That's six explicit deferrals with named owners. Exactly the framing the previous project's harness rollout established — "declare the gap, file the ticket, don't pretend it's not there."

Substantive observations on what landed

1. requires-python = ">=3.14" is the most consequential choice. Python 3.14 shipped Oct 2025; actions/setup-python@v5 supports it, uv handles it natively, and you get the full PEP 695 generics + 3.13/3.14 typing refinements. The previous project was on 3.12. The trade-off is deployment surface: anywhere that doesn't have 3.14 available yet (older Debian repos, niche cloud runtimes) needs the system Python upgraded. For a greenfield template-style project starting in 2026, defensible — and reversible if a deployment target later forces 3.12 by lowering the floor in pyproject.toml. Worth being conscious you've made the call now rather than discovering it at #17 / #18 when scaffolding ships.

2. PEP 639 license format (license = "MIT" SPDX expression + license-files = ["LICENSE"]) — the new format from 2024. Older setuptools (< 77) would warn; uv + hatchling support it cleanly. Right call for a greenfield 2026 project — locks in forward-compatibility before any tool starts deprecating the legacy license = {text = "MIT"} form.

3. [tool.uv] package = false — declares this is an application, not a library. Suppresses uv's wheel-build path, which is what removes the need for [build-system] while still letting uv sync do its venv work. This is the right pattern for an "app, deployed as a process" use case (FastAPI server) versus "library, distributed via PyPI."

4. Seed dep floors:

• fastapi>=0.115.0 — same floor as the previous project.
• pydantic>=2.11.0 — same floor as the previous project.

Both reasonable: 0.115 brought stable streaming improvements; 2.11 stabilised the strict-mode + discriminated-union behaviour you'll want for the contract layer (per feedback_otel_semconv / the StrictModel pattern from the previous project's #56). Consistent with what worked before.

5. uv.lock — 11 packages, no surprises. annotated-doc 0.0.4 is the only entry I didn't recognise — it's a recent split-off in pydantic's transitive tree. Real package, real resolution; not a typo or hijack. Trust uv.

Two minor cosmetic notes (judgment, not blocking)

Homepage and Repository URLs in [project.urls] are identical. PyPI displays them as separate links in the sidebar, so it's not wrong, but the convention is:

• Homepage = the project landing page (could be a docs site).
• Repository = the git clone URL (e.g. https://github.com/constk/harness-python-react.git).

Right now both point at https://github.com/constk/harness-python-react. Minor — would matter if/when this hits PyPI, which package = false says it won't. Take it or leave it.

description reads more like a README tagline than a typical setuptools description. "Production-quality LLM-driven coding harness — Python (FastAPI) backend, Vite + React + TypeScript frontend." That's fine — there's no hard length limit, and PyPI's "doesn't apply" guard rails are off because of package = false. Worth knowing that if you ever flip package = true, the description shows up at the top of the PyPI page where punchier-than-formal descriptions read better than this one does.

Verdict

LGTM — good to merge. gh pr merge 29 --admin --squash per project_solo_owner_admin_merge. Move #1 from In Progress → QA on the project board, then Done after merge.

After merge:

• develop has its first commit beyond the GitHub-initial state; baseline established.
• The next PR (#2 per your note) builds on this. The discipline pattern from the previous project is already in place — explicit deferral with ticket owner — so I'd expect each subsequent bootstrap PR to be similarly tight.
• One thing worth flagging about the harness-as-baseline framing: this PR is what the whole harness gets built on top of. Anything that survives the bootstrap (Python version, license format, lockfile shape, app-not-library posture) is going to be load-bearing for #2-#28. The choices you've made are conservative and defensible; just naming that the foundation matters more than a follow-on PR's choices would.

A clean restart. The "explicit deferral with owner" pattern is the bit of muscle memory that survived from the previous project — that's worth more than anything in the four files.