Design a basic storage abstraction layer for the server

[jviotti]

Signed-off-by: Juan Cruz Viotti jv@jviotti.com

[cubic-dev-ai]

1 issue found across 10 files

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/storage/storage.cc">

<violation number="1" location="src/storage/storage.cc:38">
P2: Avoid relying on assert for input validation here; in release builds a key without '/' will overflow the substring indices and yield an invalid path. Handle the missing slash with a runtime error or a fallback path.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[augmentcode]

🤖 Augment PR Summary

Summary: This PR introduces a basic Storage abstraction for the server, replacing direct std::filesystem-based path construction with key-based lookups.

Changes:

• Added a new src/storage library with sourcemeta::one::Storage for resolving keys to on-disk metapack files
• Linked the server target against the new storage library and added it to the build
• Refactored schema serving, evaluation, and search actions to read JSON/raw data via Storage instead of absolute paths
• Extended action_serve_metapack_file with overloads for local paths and storage-backed keys
• Updated server dispatch/handlers to pass a single Storage instance throughout request handling

Technical Notes: Keys are constructed via Storage::key(...) and resolved into the existing “sentinel” metapack layout (% directories), enabling future storage backend substitutions with minimal handler churn.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. 4 suggestions posted.

Comment augment review to trigger a new review at any time.