Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[ENV-C2] ADR and feasibility spike for remote isolated sandboxes (Vercel/VM)

Open
  • Is something wrong?
#276 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
backend, infrastructure

Research direction

Start by reading the linked epic #266, dependencies #267, #269 and #270, and ADRs 0002/0004/0005/0006/0008. Compare Vercel Sandbox with generic VM services against the listed trust, portability, cost, transfer and recovery requirements, then prototype scoped transfer and shutdown behavior with fake or probe tests. Done means a signed-off go/no-go ADR, integrity and recovery evidence or explicit blockers, and no remote production adapter.

Written by the indexing model from the issue text.

Description

enhancement

Artifact: decision-first design/spike task of EPIC #266. Wave: C; Size: M; Baseline: main 711ff09 (2026-10-21).

Goal and boundaries

Compare Vercel Sandbox and generic VM services as execution-only backends; specify runtime identity, short-lived credentials, streaming/heartbeat, exact Git transport, byte/size checks, remote termination, TTL/cost, remote loss and artifact recovery. Prototype only the minimum transfer and shutdown behavior; no remote production adapter.

Hard dependencies

  • #267
  • #269
  • #270

Acceptance criteria

  • Document reasoned provider comparison with capabilities/cost/trust/portability
  • Prototype integrity-bound candidate input/output (seed pack in, candidate pack and manifest out; no bind, no rsync as the content boundary) or record explicit blockers
  • Define recoverable remote resource identity and no-agent-GitHub-writes invariant
  • Demonstrate interruption and expiry fail-closed in fake/probe tests
  • Record signed-off go/no-go decision; no cloud provider declared supported prematurely
  • Negative tests and recovery tests cover the delivered behavior, with real-environment evidence or explicit unsupported reasons.
  • Maintain accepted ADRs 0002/0004/0005/0006/0008, as amended by #267's dated amendments: controller owns GitHub writes, exact-candidate verification, evidence, state transitions, and worker locks.
  • Coordinate any persisted-state schema/number with #23; preserve current bwrap behavior, avoid Sandcastle orchestrator, arbitrary mounts or credential exposure.

Verification and constraints

Implement/prototype only in scoped surface; retain the typed policy, strict subprocess argv and fail-closed required-mode. No automatic public-release claim and no hard dependency on Public Alpha #255.

Planning reconciliation (2026-10-23)

Artifact: planning update from the 2026-10-23 reconciliation of EPIC #266 with its architecture review (#266 comment). Baseline re-read: main 388ecb3. Planning only: nothing here implements a feature or checks off a criterion. The earlier sections stay authoritative where this one does not change them.

Native dependencies (verified read-back 2026-10-23): blocked_by #267, #269, #270. Wave C.

  • Wording versus the runtime model. "Streaming/heartbeat" here means the liveness of a remote execution resource, as observed by one local controller process. It is not a heartbeat protocol between AutoForge processes, a lease service or any other distributed machinery, which root AGENTS.md ("Runtime model") rules out for problems a single process holding a local lock does not have. The spike must keep that distinction and keep every workflow effect on the host.
  • Scheduler admission. autoforge epic run treats a blocker as satisfied only when it is closed as completed. This issue becomes admissible as soon as #267, #269 and #270 close, which is before the Docker MVP (#274) is done. An operator who does not want the spike to run in parallel with the MVP should leave it out of that run.
  • No-go handling. If the recorded decision is no-go, close #277 as not planned in the same action that closes this issue. #277 is natively blocked_by this issue and #274, so closing this one as completed would otherwise satisfy its blocker.
  • Egress. A remote backend's network policy is compared against #294's design questions, and its residuals are stated the same way (#270).
  • Source delivery: pack transfer only (owner decision 2026-10-23, #267 decision 12).
    • A remote sandbox never gets a bind mount, because a host path would resolve on another machine.
    • Input: the workspace seed pack, copied in. It carries the exact tree, so no separate /source copy is sent.
    • Output: a bounded Git pack plus manifest, strictly imported by the controller (#269).
    • rsync, or a provider's file-sync API, may only be a transport optimisation underneath the Git-object integrity check. It is never the content boundary, and never the way files come back.
    • The spike compares the providers on this basis: how they upload and download a pack, size limits, cost of transfer, and how a partial transfer fails.
    • Terminology: here "remote" means a remote execution sandbox, not AutoForge's REMOTE workflow mode.
Dominant language
Python
Stars
0
Forks
0
Avg merge
5h 57m
Merged PRs (30d)
71

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

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.

More from iceboundrock/AutoForge

All issues in iceboundrock/AutoForge

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.