1. Frontend
2. Backend
3. Local Git
4. Remote Git
5. GitHub

- Frontend (CLI, interactive CLI, possibly GUI) <-> Stacker
- Stacker <-> VCSBackend (Git, possibly Mercurial)
- Stacker <-> CollaborationPlatform (GitHub, GitLab, possibly BitBucket etc)
- Lander

Requirements:

- How to handle partially landed stacks?
- Handle multiple remotes (not essential for V1, but required for e.g. React)
- How to handle landing failures
- Handle commits depending on >1 commit? Let's not handle this, but let's think
  about how we can handle this
- Deployed on NPM!

Interface type improvements:

- No recursive commit structure so that we can use Immer and return new objects
  instead of mutating them.

# Components

Those in backticks are interfaces that will be implemented by concrete objects,
similar to our `NavigatorBackend` type now. In other words, a concrete `Stacker`
instance will be injected into the frontend, and this `Stacker` instance will
have concrete `VCSBackend` and `CollaborationPlatform` instances injected as
well.

## `Frontend`

CLI Commands:

- `sttack [repo_root]` - The existing interactive CLI
- `sttack rebase [repo_root] <root hash> <target hash>`
- `sttack amend [repo_root]`
- `sttack generate-branches [repo_root] <root hash>`
- `sttack pr-commit [repo_root] <commit hash>`
- `sttack pr-stack [repo_root] <root hash>`
- `sttack mr-*` - Alias for `pr-*` commands

Frontend improvements over what we currently have (excludes backend-related
improvements; this is a list of pure-UI and frontend implementation things):

- Scrolling
- Collapsing of irrelevant commits
- Differentiation between feature commits/branches and shared/long-lived
  branches (config file?)
- Loading indicators instead of reloading the entire app?
- Need keyboard commands per commit instead of commands per mode?
- Frontend itself needs further architecture design as it's currently really
  messy. I'll continue thinking about it.

## `Stacker`

Reads:

- All commits and their PR status (VCSBackend and CollaborationPlatform)
- Commit -> surrounding stack (VCSBackend)

Operations:

- Rebase (should only rebase if there's a local branch on the tip) (VCSBackend)
- Push commit on top of stack (VCSBackend)
- Amend and rebase (VCSBackend)
- Stack branch generation (I think this should be a separate step so that it's
  clearer that we're turning the commit from a nobody into a distinguished
  sttack-managed commit?) (VCSBackend)
- Create/update PRs (push stack commits/branches + PRs and descriptions)
  (VCSBackend and CollaborationPlatform)
- Update local from remote (probably need to git reset hard if stack has been
  partially landed) (VCSBackend)
- Cleanup(?) (e.g. delete unused branches)

## `VCSBackend`

Reads:

- Commits (remote stack branches should be hidden but appear as outdated or
  something?)
- Local branch <-> tracking branch comparison
- Git status
- Current branch/commit
- Branch name detection?

Operations:

- Commit amend
- Rebase/cherry pick single commit/stack/tree
- Push/force push
- Convert to stack (branch name generation. Must detect existing Stack Attack
  branches and only generate branches for commits without sttack branches. Maybe
  we can define a global Stack Attack branch prefix (configurable per repo,
  defaulting to `sttack/`), then generate a random branch name)

## `CollaborationPlatform`

Reads:

- PR info for sttack branches

Operations:

- Create/update PR for a (sub)stack given a list of (branch, commit) pairs
  (assume branch already exists on remote; commit info only needed for
  title/description)
- Update PR descriptions for a stack's PRs (**must also somehow detect and list
  landed PRs (HOW????????)**, and preserve custom description text)

## Lander

GitHub App or CLI?

# Timeline

Estimated accomplishments by the end of the weekend

- 24 July
- 31 July
- 7 Aug
- 14 Aug
  - Shipping deadline(-ish)