Portable Bridge Workspace Technical Snapshot

1. System Purpose

The project creates a portable bridge between local development, private source control, and selected public publishing. The removable drive carries the working copies, repo-hub menu, helper scripts, and handoff notes. The VPS hosts the private Git forge and acts as the durable home base. A public code host remains available for work that is intended to be open-source or public.

Trusted workstation
  -> removable bridge workspace
  -> SSH helper
  -> private VPS
  -> private Git forge

Selected public repos
  -> private forge
  -> public code host when intentionally shared

2. Storage Roles

• The removable drive is the portable workbench and handoff point.
• The VPS is the private source of truth for project history and hosted services.
• The public code host is used only for intentionally public repositories.
• Large generated artifacts are kept out of the bridge workspace unless needed for active work.

3. Trust Model

The removable drive intentionally carries SSH identity material for this workflow. That choice trades convenience and portability against physical-drive risk. The design assumes the drive is handled as a sensitive object and that a separate recovery path exists outside the drive.

• Do not print private keys, tokens, passwords, or recovery material.
• Do keep a separate administrative recovery route outside the removable drive.
• If the drive is lost, revoke its authorized public key and replace the identity.
• Keep public documentation free of provider, account, and addressing details.

4. Repository Model

Each active project is a normal Git repository. The private forge remote is used for VPS-backed history. Repositories that also belong in public can keep a public remote and use dual-push intentionally.

project working copy
  remotes:
    private -> private VPS forge
    public  -> public code host, when applicable

push policy:
  private-only work -> private remote
  public/open work  -> public remote with dual-push configured intentionally

The important rule is that publishing is explicit. Private work can move to the VPS without becoming public.

5. Repo Hub

Repo-hub is the key operator surface for this workflow. It is the first place a trusted machine or coding agent should look before touching project history.

The terminal menu discovers repositories in the workspace and shows branch, upstream, dirty state, remote configuration, and whether a repo is ready to push. It can also run pull, push, and commit-push workflows.

• Status commands are safe and non-mutating.
• Bulk push skips dirty repositories.
• Commit-push requires an explicit commit message and confirmation.
• Dirty working trees are visible before mutating actions are taken.
• The menu keeps handoff decisions out of memory and inside the workspace.

6. Website Role

The website is one project inside the same workflow. It can be built locally, pushed to the private forge, and deployed later through the VPS or another chosen publishing target. A live preview environment can exist, but it is not required for local editing.

7. Operational Boundaries

• Chat history is not the source of truth.
• The bridge workspace documentation is the local operating memory.
• The private forge is the durable project history.
• Public docs must not expose private infrastructure details.
• Destructive Git or server operations require explicit intent.

8. Failure Modes

• If the removable drive is unavailable, clone projects from the private forge.
• If the VPS is unavailable, continue local work and push when it returns.
• If the public host is unavailable, private work can still move through the VPS forge.
• If the removable drive is lost, revoke its SSH access before continuing the workflow.