docs: add todo - split file metadata into per-file IPNS objects (v2)

[FSM1]

Summary by CodeRabbit

• Documentation
  • Added new planning document detailing a design to split file metadata into per-file records, improving rename/update scope, enabling per-file sharing, and outlining migration and compatibility strategies.
  • Updated planning state with two recent decisions added to the roadmap and increased pending todo count.

[coderabbitai]

Warning

Rate limit exceeded

@FSM1 has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 19 minutes and 52 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

Walkthrough

Adds two new planning entries (crypto-related) to the repository planning state and introduces a detailed design document for evolving file metadata into per-file IPNS records.

Changes

Cohort / File(s)	Summary
Planning State .planning/STATE.md	Appends two new Recent Decisions entries and increments Pending Todos by two (now 10), referencing 2026-02-13-deterministic-vault-ipns-derivation.md and 2026-02-14-file-metadata-evolution-v2.md.
File Metadata Design .planning/todos/pending/2026-02-14-file-metadata-evolution-v2.md	Adds a detailed specification to split file metadata into per-file IPNS objects: current problem statement, folder vs per-file metadata layout, HKDF key derivation, re-publishing workflow, per-file sharing approach, backward-compatibility and migration strategy.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: adding a planning document for splitting file metadata into per-file IPNS objects, which matches the changeset of adding two files to the planning directory.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Merge Conflict Detection	✅ Passed	✅ No merge conflicts detected when merging into main

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/add-file-metadata-v2-todo

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 3

🤖 Fix all issues with AI agents

In @.planning/todos/pending/2026-02-14-file-metadata-evolution-v2.md:
- Line 38: Update the "TEE re-publishing enrollment for file IPNS records (many
more keys to manage)" note to explicitly document capacity and operational
mitigations: add a section that (1) defines TEE republisher capacity limits
(e.g., max files per vault before degraded republish latency and a recommended
soft/hard limit), (2) specifies a republish batching and parallelization
strategy (batch size, concurrency limits, backoff/retry and scheduling to meet
the <48h DHT TTL), (3) includes a short cost analysis covering IPFS node
CPU/memory, DHT bandwidth, and estimated cost per extra file based on measured
~2s/publish, and (4) provides a fallback plan (queueing, degraded consistency
modes, offloading to external republishers or rate-limiting new file IPNS
creation). Reference the existing phrase "TEE re-publishing enrollment for file
IPNS records" and ensure the new content quantifies the 21x example and gives
actionable thresholds and remediation steps.
- Line 42: The planning note currently references an external "Perplexity
research output" instead of storing the full design; update the document by
either (A) embedding the complete specification (expanded
Problem/Solution/Design sections, data model, operation flows, and
implementation checklist) directly into the existing planning note (the section
titled "Full specification with data model, operation flows, and implementation
checklist"), or (B) add a version-controlled spec file alongside planning docs
(a new planning research spec) containing the full data model, operation flows,
and checklist, then update this planning note to link to that spec with a
relative link; ensure the chosen change includes the full content so reviewers
and future maintainers can verify and access the spec.
- Around line 28-33: Clarify the batching behavior for per-file IPNS publishing
by explicitly stating that per-file IPNS records produced during a batch
operation (e.g., Phase 07.1 multi-file upload and the addFilesToFolder flow)
will be published together in a single publish call (the existing single
/ipns/publish for a 3-file batch), not as individual per-file publishes; update
the "Key design decisions needed" section to commit to batched publishing and
mention the TEE enrollment approach still supports multiple file IPNS records in
one publish for performance consistency.

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

.planning/STATE.md (1)

104-115: ⚠️ Potential issue | 🟡 Minor

Update the pending todos count.

Line 104 indicates "8 pending todo(s):" but 10 items are actually listed below. Since two new items were added (lines 108 and 110), the count should be updated to 10.

📝 Proposed fix

-8 pending todo(s):
+10 pending todo(s):