Forge Storage

forge-storage: Object and file storage

Engine: Hybrid — Forge + Supabase, Cloudflare, Google

Purpose

Inspect object naming, access control, encryption, lifecycle, consistency, integrity, and recovery.

Deterministic runtime composition

Before loading any provider procedure, run:

Resolve ../../runtime/cli/src/composition-entry.js relative to this SKILL.md, then run:

node "<resolved-absolute-runner-path>" storage compose --workflow audit --root "<repository-root>" --dry-run --json

Add one repeatable --request <provider-or-source> flag for each explicit user request. Add --condition <task-condition> or --risk-surface <surface> only for a task fact you directly proved; never infer one from generic wording. The command above is the default for this audit-oriented module; for implementation use --workflow build, and for a fix, retest, or release gate use --workflow fix, verify, or ship respectively. Read the JSON response, keep the Forge contract at index zero, and resolve paths against the absolute runtime_root reported in that response. Read eager[].runtimePath when entering the module. The full selected[] list is availability/provenance; load only deferred[].runtimePath when the task reaches that concern, in tier order. Refuse any path that escapes the root. Respect every reported suppression and context budget. If missing is non-empty, stop and report the installation as damaged; do not improvise a prose fallback. The runner and specialist content may live in a plugin cache or global installation; never assume they are inside the audited repository.

Resolve and read ../fullstack-forge/references/shared/module-contract.md (applicability, execution, mutation, verification, completion) and ../fullstack-forge/references/shared/evidence-rules.md (statuses, standards, tools, findings via ../fullstack-forge/references/PROTOCOL.md) relative to this module SKILL.md before reporting.

Never hide failed checks or claim that an operation ran when it did not.

Automatic activation signals

Activate when a request or direct repository evidence involves object and file storage, when the user explicitly names forge-storage, or when discovery proves an applicable boundary.

• Object stores, file systems, blob databases, and CDN-backed assets

When not to activate

• No persistent files or objects

Automated support

Relevant discovery inputs are:

• storage clients
• bucket and CDN configuration
• object references

Deterministic support, bounded evidence only:

• inspect-upload-pipeline

Agent inspection procedure

1. Inventory storage destinations (buckets, filesystems, database blobs) with their access policies and encryption settings.
2. Verify private-by-default access and trace every public exposure to an explicit recorded decision.
3. Check signed-URL generation for prior authorization, scope, and expiry, and object keys for server generation and tenant separation.
4. Trace lifecycle: replacement, orphan detection, account and tenant deletion, retention, and backup inclusion for stored objects.
5. Verify environment separation and quota or growth controls.

Manual inspection requirements:

• Review actual bucket, key, network, replication, and lifecycle policy
• Test provider consistency and failure assumptions

Stack-specific guidance:

• Treat presigned URLs as scoped credentials and bind method, object, size, and expiry

Evidence to collect

Standards used as criteria:

• OWASP ASVS 5.0
• CIS storage-service guidance

Common production failures

• Trace create, read, replace, copy, list, and delete authorization
• Inspect private-by-default policy, object naming, tenant prefixes, signed URL constraints, encryption, checksums, versioning, and lifecycle
• Check orphan cleanup, partial writes, metadata leakage, CDN caching, legal holds, and restore expectations

Missing-control checks

Each item needs direct evidence or one reasoned status.

• Files stored as database blobs
• Object-storage configuration
• Public versus private files
• Signed URLs
• Authorization
• Metadata
• CDN configuration
• File lifecycle
• Orphaned objects
• Deletion
• Backups
• Encryption
• Temporary files
• Retention
• Storage quotas
• Environment isolation

Commands and tools

• Run forge storage audit --json or fullstack-forge storage audit --json when an explicit audit is requested and the CLI is installed. Normal feature work does not require it.

Safe fixes

• Add integrity validation and explicit content headers
• Add cleanup for proven temporary-object leaks

Approval-required changes

• Changing visibility, retention, replication, or deleting objects

Verification

• Exercise unauthorized and cross-tenant object access
• Verify lifecycle and restore behavior with recorded provider output

Completion contract

Follow fullstack-forge/references/shared/completion.md and the limitations below.

Known limitations

• Repository configuration does not prove deployed bucket policy