Epic: Stackable UI File Browser (v0) - S3 Browser

Goal

Build a usable standalone S3 browser that lives in the Stackable UI. Read, write, preview. v0 has no Kubernetes/SDP integration. It's (for now) a standalone tool we happen to ship inside the UI.

This is v0. Several things in here are explicitly "good enough for now, must be replaced later".

Why am I structuring it like this? Because I know how tempting it is to create "the full thing" using AI. I explicitly don't want that as it makes it very hard to review. I want smaller steps that are easier to review by humans. We'll build on this in v1.

Scope

In scope

Backend abstraction

• If you can design a StorageBackend interface with S3 as the first implementation, do it. If that turns into a rabbit hole, just build S3 directly. We'll abstract once we have a real second backend (HDFS, eventually).

Connection setup

• User enters everything manually: endpoint, bucket, region, access key, secret key, plus whatever else S3 needs (path-style vs virtual-host, session token for STS, custom CA, etc. use your judgment, it doesn't have to support every S3 implementation out there. Look at our S3 CRD structures for what we at Stackable support for a good baseline).
• No Kubernetes integration. Don't read any of our CRs, don't try to be SDP-aware.

Browsing

• List, navigate, breadcrumbs, pagination
• Needs to be fast and useable even for huge lists

Preview (with hard size protection)

• General rule: every preview must have an upper bound and a clear UI signal when truncated. A 5GB log file must not crash the browser.
• JSON, Text, CSV: range-request first N bytes, never load full file. Show "preview truncated".
• Parquet: if straightforward, show schema + top N rows. If it turns into a rabbit hole, skip for v0.
• Images: Also free to skip if problematic.
• PDF: Nice to have, skip if problematic
• Build the simple cases first. Fancy previews come last or we skip them.

Write operations

• Upload.
• Download.
• Delete.
• Move and Copy. Be honest about what S3 actually does (no rename, no atomic move -> copy + delete under the hood, that was at least the case I last looked 10 or so years ago :) ). "Rename" or "Cut" sound like no-cost or low-cost operations and they might not be.

Persistence

• localStorage for user state: recent buckets, last-used paths, saved connection definitions.
• No backend persistence.
• Security note: This is shitty but fine for v0, must change before this feature ships to anyone outside Stackable.

Authorization

• Rely on upstream. If S3 returns 403 / NoSuchBucket / etc., show a clean error message. Don't try to do our own authz layer in v0.

Feature flag

• Whole feature must be behind a flag. We don't have a feature flag system yet, so building the simplest possible thing (env var, build-time toggle) is part of this Epic.
• Default OFF until the limitations below are addressed.

Out of scope for v0

Everything else :)

Open question to resolve in this Epic

Who calls S3 -> frontend or backend?

The team should decide before / during implementation. Backend-driven is probably the right long-term answer. It does not need to be secure in v0.

Acknowledged v0 limitations (must be replaced before this ships beyond v0)

• Credentials handling is not production-grade. Whether they live in localStorage or get POSTed to the backend, v0 isn't solving the credential problem properly.
• No authz beyond what S3 enforces on the typed creds. No OPA integration.
• No SDP integration. Standalone tool.
• Feature flag stays off by default until the above are resolved