# Project Mycelium

## Overview

- The Project Mycelium follows devops procedures and open-source + Agile philosophy
- For devs, we must develop and code until the Project Mycelium is production-ready and can be run by an ops team (1+ person) to deploy and maintain the marketplace
- In practical sense, once tested by users online, we gather feedback and create issues and then PRs to fix them (as in problem+solution forward & dynamic solution approach).
- By design, we present a clear roadmap and phases, such as internal, external and public testings

Last updated: 2025-08-12

## Phases by Outcome

- Alpha (UI only, local/git persistence)
  - DoD: user can browse, add to cart; no backend calls; basic UX validated
- Beta (PostgREST + Stripe integrated)
  - DoD: end-to-end test purchase on dev succeeds; errors logged; basic monitoring
- GA (HA on Kubernetes on ThreeFold Grid)
  - DoD: self-healing deployment; no single point of failure; metrics + alerts; backup/restore tested

```mermaid
flowchart LR
  Dev[Local Dev] --> DevEnv[Dev Environment]
  DevEnv -->|Optional| Stg[Staging]
  Stg --> Prod[Production]
  Dev -. Issues/PRs .-> Dev
  DevEnv -. Feedback .-> Dev
```

## Workflow

- Branching: feature/* → PR → development; merge to main when deploy-ready
- Issues → PRs: problem → solution; keep PRs small; fast review/merge
- Testing lanes: local → dev (shared) → staging (optional) → prod
- Docs: update `docs/dev/method/current/design_method.md` and `docs/ops/method/current/deployment_method.md` with each change

## Definition of Done (per PR)

- Lints/tests pass; basic manual check done
- Docs updated (design or ops as relevant)
- Linked issue closed with notes on acceptance criteria

## References

- Dev design method: `docs/dev/method/current/design_method.md`
- Ops deployment method: `docs/ops/method/current/deployment_method.md`