docs: position GoBarryGo as a native work suite

CHANGELOG.md

@@ -1,5 +1,12 @@
 # Changelog
 
+## Unreleased
+
+- **Positioned:** GoBarryGo is now documented as a native general-work suite with
+  the downloader as its first complete module.
+- **Documented:** Added a staged roadmap for downloader completion, a file workspace,
+  batch tools, and later workflows. Future modules remain explicitly unshipped.
+
 ## 0.0.9 CHITRA - 2026-06-16
 
 - **Added:** Downloader metrics strip for current speed, peak speed, active ETA, backlog, queue state, connections, and issues.

README.md

@@ -1,6 +1,8 @@
 # GoBarryGo
 
-GoBarryGo is a lightweight native desktop download manager for `aria2c`, built from scratch with Go, Wails v3 alpha, Bun, React 19, and TypeScript. Version `0.0.9` is codename `CHITRA`.
+GoBarryGo is a low-overhead native general-work suite, starting with a focused desktop downloader for `aria2c`. It is built from scratch with Go, Wails v3 alpha, Bun, React 19, and TypeScript. Version `0.0.9` is codename `CHITRA`.
+
+The product direction is deliberately staged: make the downloader excellent first, then add small local-first work modules inside the same native shell. The suite is not claiming those future modules are shipped yet.
 
 ## What It Does
 
@@ -10,6 +12,22 @@ GoBarryGo is a lightweight native desktop download manager for `aria2c`, built f
 - Ships cross-platform packaging for Linux, Windows, and macOS through GitHub Actions.
 - Keeps the frontend bundle small and the app architecture thin by treating Wails as transport and packaging glue instead of the application core.
 
+## Product Direction
+
+GoBarryGo should feel like one dependable native workspace rather than a pile of unrelated utilities. Every module must be useful on its own, share the same job/history/safety language, and remain local-first by default.
+
+### Current module: Downloader / Inbox
+
+This is the shipped `0.0.9` surface. It owns URL intake, parallel transfer, resume/retry, queue state, engine health, file inspection, and the handoff from a network job to a local file.
+
+### Planned modules
+
+1. **File workspace** — safe staging, rename/move, checksum verification, and clear post-download handoff.
+2. **Batch tools** — previewable batch rename, copy, archive, and inspection jobs with conservative defaults.
+3. **Workflows** — GUI-authored sequences with timers, bounded resources, readable script export, and later desktop/server service runs.
+
+These are roadmap items, not current release features. See [the detailed product roadmap](docs/product-roadmap.md) for scope, sequencing, and acceptance gates.
+
 ## Product Decisions
 
 - Release artifacts can include a bundled `aria2c` fallback. A custom Preferences path wins first, then `PATH`, then the bundled binary.
@@ -36,6 +54,8 @@ GoBarryGo is a lightweight native desktop download manager for `aria2c`, built f
   - auto rename behavior
   - completion and failure notifications
 
+The downloader is intentionally the first complete module. New capabilities should earn a place by making a repeatable work task faster, safer, or easier to inspect; general-purpose features are not added merely to make the product sound broad.
+
 ## Requirements
 
 - Go `1.26.0`
@@ -135,5 +155,7 @@ Not fully verified locally:
 - [Releasing](docs/RELEASING.md)
 - [Domain and release contract](docs/domain-release.md)
 - [Distribution status](docs/distribution-log.md)
+- [Product roadmap](docs/product-roadmap.md)
+- [Workflow design](docs/workflows.md)
 - [Changelog](CHANGELOG.md)
 - [Third Party Notices](THIRD_PARTY_NOTICES.md)

docs/ARCHITECTURE.md

@@ -1,6 +1,11 @@
 # Architecture
 
-GoBarryGo is organized around one rule: keep Wails thin and keep application logic portable.
+GoBarryGo is organized around two rules: keep Wails thin and keep application logic
+portable; grow the product as small native modules inside one consistent shell.
+
+The shipped release is downloader-first. The module boundary below is the target
+shape for the suite and does not imply that future file, batch, or workflow modules
+already exist.
 
 ## Layers
 
@@ -33,6 +38,34 @@ GoBarryGo is organized around one rule: keep Wails thin and keep application log
 - `frontend/src/lib/wails` isolates generated bindings and Wails event subscription details.
 - `frontend/src/features/*` keeps view logic grouped by product surface instead of by generic component type.
 
+### Future module boundary
+
+When a second module is introduced, keep the shell and module responsibilities
+explicit:
+
+- The shell owns navigation, settings, lifecycle, shared job state, notifications,
+  and the selected-module context.
+- A module owns its domain commands, validation, progress details, and recovery
+  rules. The downloader is the first example of this boundary.
+- Long-running work is represented as a typed, cancellable job with a visible state
+  (`queued`, `running`, `paused`, `completed`, `failed`, or `cancelled`).
+- Module code stays in plain Go or framework-independent TypeScript where possible;
+  Wails bindings remain an adapter at the edge.
+- Local records are versioned and exportable. No account, telemetry, or cloud sync is
+  required for a module to function.
+- The workflow runner is headless-capable but GUI-first in product design: the GUI
+  authors and observes runs, while the same plain-Go executor can run an exported
+  definition from a desktop or service host.
+- Resource limits belong to the runner boundary, not only the React UI. Worker caps,
+  memory/CPU admission, disk reserves, cancellation, and child-process containment
+  must remain enforceable when no window is open.
+
+The first likely addition is a File Workspace for downloaded outputs, followed by
+previewable Batch Tools. A workflow layer comes later, after job history and recovery
+are proven. Its GUI-to-headless execution contract, resource governor, and service
+targets are documented in [Workflows](workflows.md). See [the product roadmap](product-roadmap.md)
+for the sequencing and release gates.
+
 ## State Flow
 
 1. The frontend calls `Bootstrap`.

docs/design/native-ui-v1.md

@@ -9,9 +9,14 @@ References:
 
 ## Product intent
 
-GoBarryGo is a small native control surface for `aria2c`. The redesign should make the
-queue faster to scan without adding cloud accounts, telemetry, generic analytics, or
-features that duplicate `aria2c` without improving its desktop use.
+GoBarryGo is a small native work shell whose first complete module is a focused
+control surface for `aria2c`. The redesign should make the queue faster to scan and
+leave room for later local-first work modules without adding cloud accounts,
+telemetry, generic analytics, or features that duplicate `aria2c` without improving
+its desktop use.
+
+The downloader remains the quality bar: every future module must be as inspectable,
+low-overhead, and focused as this workspace.
 
 ## Visual system
 

docs/distribution-log.md

@@ -2,12 +2,13 @@
 
 Canonical product URL: <https://gobarrygo.shreyam1008.com.np/>  
 Repository: <https://github.com/shreyam1008/gobarrygo>  
-Last checked: 17 August 2026, 15:42 IST
+Last checked: 17 August 2026, 20:10 IST
 
 This file separates public availability from repository preparation. A package manifest or workflow is not evidence that a store listing is live.
 
 | Channel | Version | Status | Evidence / next check |
 | --- | --- | --- | --- |
+| Product website | v0.0.9 | **Live** | `https://gobarrygo.shreyam1008.com.np/` returned strict HTTPS 200 with the custom-domain page and matching canonical metadata on 17 August 2026. |
 | GitHub Releases | v0.0.9 | **Live** | The public [v0.0.9 release](https://github.com/shreyam1008/gobarrygo/releases/tag/v0.0.9) returned HTTP 200 without authentication on the check date. |
 | WinGet | v0.0.9 | **Prepared; public listing unverified** | Repository manifests exist under `packaging/winget/`; submission or catalog availability was not verified. |
 | Snap Store | v0.0.9 | **Prepared; not published** | `snap/snapcraft.yaml` and packaging instructions exist; no public store URL is recorded. |

docs/domain-release.md

@@ -1,11 +1,11 @@
 # Product domain and release contract
 
-`dbterm` is the live reference implementation. The other rows are preparation targets; repository changes alone do not make a domain live.
+`dbterm` is the live reference implementation. GoBarryGo is now also live; the other rows are preparation targets. Repository changes alone do not make a domain live.
 
 | Product | Canonical URL | Pages source | Status |
 | --- | --- | --- | --- |
 | dbterm | `https://dbterm.shreyam1008.com.np/` | `gh-pages` (site plus APT metadata) | **Live** |
-| GoBarryGo | `https://gobarrygo.shreyam1008.com.np/` | GitHub Actions | **Prepared; deployment and public checks pending** |
+| GoBarryGo | `https://gobarrygo.shreyam1008.com.np/` | GitHub Actions | **Live; verified 2026-08-17** |
 | Visualise OKLCH | `https://visualise-oklch.shreyam1008.com.np/` | GitHub Actions | **Prepared; deployment and public checks pending** |
 | shre-skills | `https://skills.shreyam1008.com.np/` | GitHub Actions | **Prepared; deployment and public checks pending** |
 

docs/product-roadmap.md

@@ -0,0 +1,174 @@
+# GoBarryGo product roadmap
+
+Status: direction approved; only the Downloader / Inbox module is shipped.
+
+GoBarryGo is evolving from a downloader into a native, low-overhead general-work
+suite. The product should still feel like one tool: one shell, one job model, one
+history, and one set of safety conventions. The roadmap is intentionally sequential
+so each module can become genuinely useful before the next one is added.
+
+## Product promise
+
+> Small native tools for repeatable work, with the downloader as the first complete
+> workflow.
+
+The suite is local-first and transparent. It should work without an account, keep
+user files on the user's machine, explain what a job is doing, and make recovery or
+rollback understandable. A feature does not belong in the suite just because it is
+technically possible.
+
+## Current state: Downloader / Inbox
+
+The `0.0.9 CHITRA` release is the first module and the reference for future work.
+It currently provides:
+
+- URL intake for one or many links, with output name, directory, headers, and
+  User-Agent overrides.
+- A native queue for pause, resume, retry, remove, open, reveal, and global pause /
+  resume actions.
+- A managed `aria2c` process with health/error visibility and session recovery.
+- Live speed, ETA, progress, transfer, connection, and issue signals.
+- Preferences for concurrency, splits, connections, allocation, resume, rename, and
+  notifications.
+- Cross-platform release artifacts and a small Wails/Go/React footprint.
+
+The first module is not finished merely because it downloads a file. It is finished
+when the whole path from link to trusted local file is easy to inspect and recover.
+
+## Downloader completion track
+
+These are the next delivery slices, in order. Each slice should be a small release
+with a focused test and browser/native QA record.
+
+### D1 — Trustworthy history and search
+
+- Persist completed, failed, cancelled, and removed jobs with timestamps and source
+  host.
+- Search and filter by filename, host, status, and date.
+- Keep a clear distinction between a job record and the file it produced.
+- Add export/import of history without copying downloaded file contents.
+
+Gate: a user can find any previous job, understand its final state, and reopen or
+reveal its output without restarting the app.
+
+### D2 — Per-job control and recovery
+
+- Per-job concurrency and priority overrides where aria2c supports them.
+- Bounded retry with visible backoff and the last meaningful error.
+- Graceful aria2c restart and reconciliation after an app or engine crash.
+- Duplicate detection by normalized URL plus destination, with an explicit override.
+
+Gate: interrupting the engine or network does not silently duplicate, lose, or mark
+a file complete.
+
+### D3 — Integrity and handoff
+
+- Optional checksum input and post-download verification.
+- Clear partial, verified, failed, and unknown-integrity states.
+- Safe “open”, “reveal”, and “move to workspace” actions with confirmation for
+  destructive operations.
+- Per-file details for multi-file downloads.
+
+Gate: the user can tell whether a file is merely transferred or actually verified.
+
+### D4 — Network profiles and scheduling
+
+- Named bandwidth/concurrency profiles (for example: Quiet, Normal, Fast).
+- Start-at-time and pause-at-time schedules that survive a restart.
+- Import/export of settings with secrets and headers clearly excluded or redacted.
+
+Gate: schedules are deterministic, visible, cancellable, and never block ordinary
+manual downloads.
+
+## Suite expansion
+
+Only begin a new module after D1–D3 are stable and the shared shell contract exists.
+
+### M1 — File workspace
+
+Purpose: finish the handoff from a network job to local work.
+
+Initial scope:
+
+- A local staging view for recent outputs and folders.
+- Rename and move with preview, conflict handling, and an undo-friendly operation
+  record.
+- Checksum and metadata inspection reused from the downloader.
+- Open/reveal actions that respect the operating system and never guess a path.
+
+Not in the first slice: a full file manager, cloud drive, or background index of the
+entire disk.
+
+### M2 — Batch tools
+
+Purpose: make repetitive local operations quick without hiding side effects.
+
+Initial scope:
+
+- Batch rename with a preview and reversible operation list.
+- Copy, move, archive, and extract jobs with progress and cancellation.
+- Hash/verify jobs for a selected set of files.
+- A shared job history and error presentation.
+
+Not in the first slice: arbitrary shell execution or opaque “cleaner” actions.
+
+### M3 — Workflows
+
+Purpose: compose proven jobs into small, inspectable routines.
+
+Initial scope:
+
+- A simple ordered workflow: intake → transfer → verify → move.
+- Manual run first; scheduling only after recovery is reliable.
+- Per-step logs, cancellation, retry policy, and a final summary.
+
+Not in the first slice: a general visual programming language, cloud sync, or a
+marketplace of untrusted plugins.
+
+The detailed execution, resource-governor, generated-script, and Windows Server
+plan lives in [Workflows](workflows.md).
+
+## Native shell contract
+
+The current UI is downloader-first. When the second module begins, introduce the
+smallest shared shell that can host both surfaces:
+
+- A compact module rail with an obvious active module and keyboard navigation.
+- A shared job center for active, queued, finished, failed, and cancelled work.
+- A shared inspector pattern for inputs, progress, output, warnings, and actions.
+- A shared notification and error vocabulary; no silent background work.
+- A local data directory with versioned migrations and exportable records.
+- A capability boundary: each module owns its domain logic, while the shell owns
+  navigation, jobs, settings, and lifecycle.
+
+Keep Wails as transport/packaging glue. Core jobs and safety rules remain plain Go so
+they can be tested without a window and survive framework churn.
+
+## Quality and release gates
+
+Every new module must satisfy all of these before it is called shipped:
+
+1. A user-facing problem statement and explicit non-goals.
+2. A typed core contract with unit tests independent of Wails.
+3. Cancellation, retry, restart, and error states represented in the UI.
+4. No destructive default; preview or confirmation where data can be changed.
+5. Local-first behavior documented, including where data and logs are stored.
+6. Desktop and narrow-window QA, keyboard/focus checks, and no relevant console
+   errors.
+7. Release artifacts, checksums, install/uninstall notes, and a truthful distribution
+   status in `docs/distribution-log.md`.
+8. README, product manifest, site metadata, and the portfolio catalog updated in the
+   same change.
+
+## Decision log
+
+- **2026-08-17 — Downloader first:** GoBarryGo is not being rebranded or split into
+  separate utilities. The existing downloader is the first complete module and the
+  quality bar for the suite.
+- **2026-08-17 — Native/local-first:** keep the Go + Wails shell small, avoid an
+  account/cloud dependency, and preserve inspectable local jobs.
+- **2026-08-17 — Staged expansion:** file work, batch tools, and workflows are
+  planned but remain clearly marked as future work until their gates pass.
+- **2026-08-17 — GUI-first, headless-capable:** the GUI is the authoring and
+  observability surface; a shared Go runner can execute exported workflows on a
+  desktop or server without making the product CLI-first.