docs: spec for project metadata

[Pertempto]

• Added project metadata spec
• Added spec validator
• Ran pre-commit run --all-files to clean stuff up

[github-actions]

specs/009-project-metadata.md: Please add an explicit example of the data.json layout showing the new projects key (a small JSON snippet). This should include at least one project with name and code so implementers know exact field names and nesting to expect.

[github-actions]

specs/009-project-metadata.md: Clarify project-name matching and uniqueness: specify whether name is case-sensitive, whether leading/trailing whitespace is normalized, and whether name must be unique. Also define behavior when renaming a project — should existing time entries be rewritten to the new name or should exports resolve codes by historical name? Add explicit rules so implementers can handle matching and migrations deterministically.

[github-actions]

Changes Requested

Please make the following changes to the spec before I can approve:

• Add a small data.json example showing the new top-level projects key with at least one project (include name and code and optional category if you adopt it).
• Define project-name matching rules: uniqueness requirement, case-sensitivity, whitespace normalization, and exact behavior when renaming a project (whether existing time entries are rewritten or exports resolve by historical name).
• Decide whether to include the proposed third field category (author suggested). If included, add it to the fields table and example and state whether it is required/enum/ free-form.
• Clarify export header names/casing and delimiter (CSV vs TSV) and add a short migration note for external parsers if header names change.
• Confirm the .envrc entry in .gitignore is intentional and add a short comment in the file explaining why it is ignored.

Summary of Changes

• Added spec: specs/009-project-metadata.md (new draft spec describing project metadata)
• Modified .gitignore to include .envrc

Overall Feedback

• What needs work: The spec outlines a useful feature but currently lacks concrete schema examples and deterministic rules for name matching and migrations. Those gaps will make implementation and data migration error-prone.

• What I liked: The proposal is focused, the task list is comprehensive, and the export and TUI considerations show good end-to-end thinking. Once the schema + matching/migration rules are explicit, this will be straightforward to implement. Nice work! 🚀

If you want, I can suggest a canonical projects JSON snippet and a short rename/migration strategy to include in the spec — ping me and I will add it.