NEARBuilders / NEARBuilders/everything-dev

v2-platform: 01 deploy service core — contract, eligibility, ledger, local storage provider

Open
#275 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

ready-for-agent
Dominant language
TypeScript
Stars
5
Forks
6
Avg merge
1m
Merged PRs (30d)
1

Description

Parent

#274 (v2 platform services spec)

What to build

The deploy service core as a platform plugin: an authenticated oRPC contract that accepts a built workspace upload, checks deploy eligibility (organization membership, resolved in-process against the auth plugin), stores the bundle through a swappable storage-provider adapter (local-disk implementation for now — no cloud), and records a deployment ledger entry (account, workspace, content-hash, entry URLs, SRI integrity). List/read endpoints return a deployment history. Everything verifiable through the contract surface with the repo's pglite test pattern. This is the seam every later ticket (CLI, real CDN, gasless publish, member subdomains) builds on.

Acceptance criteria

  • Upload of a workspace dist through the deploy contract returns a deterministic content-hashed URL (same input → same URL, deduped on re-upload)
  • Uploads from accounts that are not org members are rejected at the eligibility gate; org-member accounts succeed
  • Each deployment produces a ledger record readable via the list/read contract endpoints
  • SRI integrity is computed and stored with each deployment entry
  • The storage provider is an adapter: the local-disk implementation can be swapped without contract or ledger changes
  • Contract-level tests cover the happy path, eligibility rejection, and deterministic-URL/dedupe behavior (pglite pattern)

Blocked by

  • Epic #248 (oRPC v2 / Effect 4 migration) reaching B8 — the deploy service is built Effect-native from day one.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the v2 platform services spec in #274 and verify that the oRPC v2 / Effect 4 migration in #248 has reached B8 before beginning. Follow the repository's pglite contract-test pattern and define the deploy contract, eligibility gate, storage adapter, and ledger boundaries from the acceptance criteria. Done means the happy path, rejection, deterministic deduplication, SRI, and list/read behavior are covered by contract-level tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
api, authorization, backend, databases, testing
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.