Add TODO section to README with 1.0 roadmap, remove TODO.md

Perform design and status review of the codebase. Add a comprehensive
TODO section to README.md covering design questions requiring owner
input, implementation tasks (repo infrastructure, format, library, CLI,
testing, documentation), and release checklist.

Integrate items from TODO.md into the README TODO section and remove
TODO.md from the repo. Update AGENTS.md to reference the new location.

README.md

@@ -25,7 +25,8 @@ software. A compatible javascript library is planned.
 
 # Build Status
 
-[![Build Status](https://drone.datavi.be/api/badges/sneak/mfer/status.svg)](https://drone.datavi.be/sneak/mfer)
+CI runs via `docker build .` which executes `make check` (formatting,
+linting, tests). The `main` branch must always be green.
 
 # Participation
 
@@ -208,6 +209,131 @@ regardless of filesystem format.
 Please email [`sneak@sneak.berlin`](mailto:sneak@sneak.berlin) with your
 desired username for an account on this Gitea instance.
 
+# TODO: Remaining Work for 1.0
+
+## Design Questions (Owner Decision Required)
+
+These require @sneak's input before implementation. Answers should be added
+inline below each question.
+
+**1. Should `MFFileChecksum` be simplified?** Currently it's a separate
+message wrapping a single `bytes multiHash` field. Since multihash
+already self-describes the algorithm, `repeated bytes hashes` directly on
+`MFFilePath` would be simpler and reduce per-file protobuf overhead. Is
+the extra message layer intentional (e.g. planning to add per-hash
+metadata like `verified_at`)?
+
+> _answer:_
+
+**2. Should file permissions/mode be stored?** The format stores
+mtime/ctime but not Unix file permissions. For archival use this may not
+matter, but for software distribution or filesystem restoration it's a
+gap. Should we reserve a field now (e.g. `optional uint32 mode = 305`)
+even if we don't populate it yet?
+
+> _answer:_
+
+**3. Should the `manifest` type be exported?** Currently unexported with
+exported constructors (`NewManifestFromReader`, `NewManifestFromFile`).
+Consumers can't declare `var m *mfer.manifest`. Export the type, or
+define an interface?
+
+> _answer:_
+
+**4. What should the Go module path be for 1.0?** Currently
+`sneak.berlin/go/mfer` in `go.mod` but `git.eeqj.de/sneak/mfer/mfer` in
+the proto `go_package` option. Which is canonical?
+
+> _answer:_
+
+**5. GPG vs pure-Go crypto for signatures?** Shelling out to `gpg` is
+fragile (may not be installed, version-dependent output).
+`github.com/ProtonMail/go-crypto` provides pure-Go OpenPGP, or we could
+use Ed25519/signify (simpler, no key management). Which direction?
+
+> _answer:_
+
+**6. Should we add a version byte after the magic?** Currently
+`ZNAVSRFG` is followed immediately by protobuf. Adding a version byte
+(`ZNAVSRFG\x01`) would allow future framing changes without requiring
+protobuf parsing to detect the version. `MFFileOuter.Version` serves
+this purpose but requires successful deserialization to read. Worth the
+extra byte?
+
+> _answer:_
+
+**7. Should we add a length-prefix after the magic?** Protobuf is not
+self-delimiting. If we ever want to concatenate manifests or append data
+after the protobuf, the current framing is insufficient. Add a varint or
+fixed-width length-prefix?
+
+> _answer:_
+
+## Implementation Tasks
+
+### Repo Infrastructure
+
+- [ ] Add `.golangci.yml` (fetch from
+      `https://git.eeqj.de/sneak/prompts/raw/branch/main/.golangci.yml`)
+- [ ] Add `.editorconfig`
+- [ ] Add `.gitea/workflows/check.yml` that runs `docker build .`
+
+### Format & Correctness
+
+- [ ] Resolve proto `go_package` path inconsistency
+      (`git.eeqj.de/sneak/mfer/mfer` vs `sneak.berlin/go/mfer`)
+- [ ] Reserve `optional uint32 mode = 305` in `MFFilePath` for future
+      file permissions (pending design question answer)
+- [ ] Add version byte after magic — `ZNAVSRFG\x01` for format version
+      1 (pending design question answer)
+
+### Library
+
+- [ ] Export the `manifest` type or define a public interface (pending
+      design question answer) — currently consumers cannot hold a reference
+      to a loaded manifest in their own type declarations
+- [ ] Replace GPG subprocess calls with pure-Go crypto (pending design
+      question answer) — current implementation shells out to `gpg` which
+      may not be installed
+
+### CLI
+
+- [ ] Wire `--version` flag properly (currently only a `version`
+      subcommand exists; top-level `--version` shows urfave/cli generic
+      output)
+- [ ] Add `--deterministic` flag documentation — deterministic output is
+      the default, but this isn't obvious from CLI help
+- [ ] Add retry logic to `fetch` — currently no retries on transient
+      HTTP errors; needs exponential backoff
+- [ ] `fetch` command uses bare `http.Get` with no timeout — needs
+      `http.Client` with configurable timeout
+
+### Testing & Robustness
+
+- [ ] Add fuzzing tests for `NewManifestFromReader` — protobuf
+      deserialization of untrusted input needs fuzz coverage
+- [ ] Add integration test for `freshen` CLI command — current tests
+      only verify setup, not the actual freshen operation end-to-end
+- [ ] Add test for `fetch` CLI command end-to-end (currently only
+      `downloadFile` is tested)
+
+### Documentation
+
+- [ ] Write standalone format specification document — `FORMAT.md`
+      exists but should be promoted to the primary spec reference; README
+      should link to it more prominently
+- [ ] Audit and update all error messages for consistency and
+      helpfulness
+- [ ] Document the signature scheme more thoroughly (canonical string
+      format, verification steps)
+
+### Release
+
+- [ ] Finalize Go module path
+- [ ] Update version constant in `mfer/constants.go`
+- [ ] Add `--version` output matching SemVer
+- [ ] Tag `v1.0.0`
+
 # See Also
 
 ## Prior Art: Metalink