Weekly Product Notes: Files, Runs, and Portable Projects

This week was about making Bridge Town feel less like a collection of tools and more like an operating system for finance models.

The work landed across several layers: project files became easier to browse and open, model runs became more expressive, .btx portability moved from design into working implementation, and the production path picked up a lot of hardening. Some of it is visible in the app. Some of it is the kind of infrastructure work that users only notice when nothing breaks.

Project files are now the primary model surface

The largest user-facing change was the move from model-era routes toward project-relative files.

Bridge Town now treats files and folders as first-class project objects. The project page was migrated off the removed model CRUD path and onto the file CRUD surface, folder rows became actionable, and nested directories can be navigated without flattening everything into the root view.

We also fixed the follow-on routing problem that showed up after folder browsing landed. Nested file links can no longer rely on encoded slashes inside a single route segment. File detail pages now use a dedicated file?path=... pattern so paths such as model/customer_cohort.py work in production routing, refresh correctly, and preserve branch context.

For finance teams, the practical outcome is simple: a project can now look like a real code and data workspace. README.md, model/, data/, docs/, and deeper folder layouts are visible and navigable from the product surface.

Model runs gained more shape

Execution work moved in two directions: richer outputs and more flexible inputs.

Run outputs can now be fetched and compared with clearer structured behavior. Named run outputs, persisted output comparison, and export support for XLSX and PDF improve the handoff from model execution to analysis and reporting.

The biggest new capability is parameterized model runs. A run can now carry explicit JSON-serializable runtime parameters, persist enough metadata for later audit, and deliver the parameter payload into the sandbox through /inputs/parameters.json. That creates a cleaner path for sensitivity cases such as discount_rate=8% versus discount_rate=10% without requiring a branch for every assumption tweak.

This does not replace branch-based scenario analysis. Branches are still the right tool when model logic changes. Parameters are for runtime assumptions that should be explicit, repeatable, and comparable.

.btx portability moved from spec to implementation

The .btx archive format took a major step forward.

This week added archive primitives, export APIs, MCP surfaces, import upload validation, conflict policy handling, lifecycle audit events, target-workspace membership checks, and reconstruction of imported projects across Postgres, Gitea, and S3. The CLI wrappers and user documentation also landed, along with an end-to-end validation path.

The theme is controlled portability. A Bridge Town project should be movable without carrying over source-instance secrets, social state, stale tenant identifiers, or unsafe access grants. The implementation now reflects that boundary more directly.

Billing, deployment, and production checks got harder to fool

Several changes focused on operational confidence.

Billing now handles Stripe object normalization more consistently, reconciles stale plan state, and supports cancellation, downgrade, and customer portal flows. Checkout success now upgrades tenant plan state more reliably, which closes a gap between payment events and the app’s own authorization view.

On deployment, the GitHub OIDC and EC2 SSM path was tightened with better preflight checks, explicit AWS region configuration, safe-directory handling for SSM-run git commands, deploy log redirection to avoid SSM IPC failures, and saved-dashboard CSP smoke verification. The production environment also picked up telemetry configuration checks so missing PostHog values are caught earlier.

These are not glamorous changes. They are the difference between a deploy pipeline that usually works and one that explains itself when it cannot.

The MCP surface is cleaner and more project-oriented

MCP work continued to reduce ambiguity in tool names, error shapes, and project language.

The old model CRUD vocabulary has been replaced by path-scoped file tools, with branch-aware reads and writes, shared path validation, byte-safe Gitea primitives, and REST parity tests. Deprecated shim tools were removed, tool descriptions were refreshed, and generated tool documentation now includes more agent-usable examples and response schemas.

There was also work on commentary and collaboration primitives: atomic multi-file commits, run commentary tools, append-only version history, optimistic concurrency around commentary updates, and route-bound REST commentary APIs.

For users and agents, the direction is intentional: fewer hidden aliases, fewer internal implementation leaks, and clearer contracts around projects, files, runs, and outputs.

Security and auth fixes continued in the background

The week included a long tail of security and boundary fixes.

Examples include tighter project access checks for run cancellation, structured errors that avoid leaking internal IDs, file CRUD validation for path and encoding failures, safer CSP behavior around fonts and analytics, Auth0 logout routing fixes, Google Sheets session cookie improvements, workspace RLS fixture cleanup, and production dashboard asset-origin checks.

These changes mostly reduce surprise. The app should expose the right error at the right boundary without telling one tenant anything about another tenant’s state.

Documentation and public surfaces caught up

The docs and landing site also moved.

Tool docs were regenerated, billing and plan-limit documentation landed, data integration and dashboard guides were refreshed, MCP guidance was swept for canonical tool names, and public language continued moving away from implementation terms such as repos and Git toward user-facing project history and files.

That language shift matters. Bridge Town is built on familiar technical primitives, but finance teams should not have to think like infrastructure operators to understand their planning system.

What this means

The product is converging around a clearer mental model:

• Projects contain files and folders.
• Runs produce auditable outputs.
• Parameters capture explicit assumptions.
• Archives move projects without moving unsafe state.
• Deploys and billing events have stronger verification.

That is the operating layer Bridge Town needs before higher-level FP&A workflows can feel fast without becoming opaque.

Next, we expect the visible product work to build on these foundations: richer scenario workflows, cleaner project navigation, and more direct ways for finance teams to compare model behavior without losing auditability.