Blooming developer infrastructure — a cohesive, Free & Open Source (Apache 2.0) toolchain spanning secret detection, configuration management, documentation generation, temporal scheduling, workflow ergonomics, and (future) adaptive pipeline orchestration.
Philosophy: Shift-left tooling should feel elegant, composable, and emotionally lightweight—technical precision with poetic restraint.
Pillar | Focus | Guiding Idea |
---|---|---|
Clarity | Developer-first UX | Minimal friction; explicit > implicit |
Signal | Reduce noise | Deterministic + heuristic balance |
Extensibility | Modular layers | Each project useful alone, stronger together |
Transparency | FOSS & auditable | No opaque logic; human-readable rules/config |
Resilience | Adaptive flows | Future orchestration that can evolve safely |
Aesthetic | Sakura identity | Gentle visuals & language without obscurity |
sakura-secrets
Developer-first secret & credential scanner (FOSS). Early concept stage, focusing on:
- Future regex + entropy detection
- Baseline suppression model
- Git-aware scan modes
- Planned interactive TUI (Bubble Tea)
Forge Config
Composable configuration loader/merger (files + env + profiles) with schema validation. Foundation piece reused across the stack.
Petal Docs
Sakura-themed documentation generator (Markdown → static site) emphasizing readability, subtle motion, and writer ergonomics.
Bloom CLI
Unified CLI entrypoint and workflow DSL scaffolder. Starts simple (init / lint / plan) and later bridges into orchestration.
Rhythm Engine
Deterministic scheduling core with jitter/backoff + future “pattern” combinators (temporal textures for task timing).
Sakura Pipeline
Adaptive workflow & task orchestration with deterministic resumption, version-aware evolution, and stateful recovery (top-of-stack integration).
forge-config → shared configuration substrate
petal-docs → human-facing documentation layer
sakura-secrets → guardrail at the edge (repos / CI)
rhythm-engine → low-level temporal primitives
bloom-cli → interface & UX seed for flows
sakura-pipeline → composition + resumption + orchestration
Each layer is:
- Useful standalone
- Exposes clean APIs / formats
- Avoids tight coupling via stable contracts
- Deterministic cores + ergonomic shells
- Declarative & inspectable YAML / JSON surfaces
- Progressive adoption (no forced platform lock-in)
- Separation of engine / rules / presentation
- Pragmatic performance (optimize after correctness)
- FOSS license continuity (Apache 2.0 across primary projects)
Phase | Focus |
---|---|
0 | sakura-secrets conceptual + rule engine scaffold |
1 | forge-config MVP + org baseline tooling |
2 | petal-docs (internal + public docs) |
3 | bloom-cli prototype (workflow schema draft) |
4 | rhythm-engine (scheduler primitives) |
5 | pipeline alpha (minimal DAG + resumable state) |
6 | integration hardening + developer tutorials |
- Terminology: petal, bloom, rhythm, forge, flow
- Tone: Calm, precise, inviting
- Avoid: Overwrought metaphors that obscure technical affordances
Early phases emphasize:
- Clear architectural notes over premature abstraction
- Small, documented PRs
- Reproducible test fixtures
- Explicit failure modes
- Transparent tradeoffs (README “why” sections)
Contribution docs (CONTRIBUTING, SECURITY, CODE_OF_CONDUCT) will appear as each repo reaches a functional prototype.
Primary license: Apache 2.0
Rationale: permissive FOSS, explicit patent grant, future-proof for optional open-core extensions without restricting the community core.
- Closed-core feature gating
- Vendor lock-in orchestration
- Magic “AI” black-box automation
- Fragile DSLs without escape hatches
Influenced by ecosystems like: Temporal, Airflow, Dagster, Gitleaks, Bubble Tea, Rust scheduling crates — and the broader craft community that values both clarity and character.
- ⭐ Star repos to follow iteration
- Open discussions (when enabled) for design debates
- Suggest rule patterns, config merge semantics, or scheduler primitives
“Bloom steady. Build tools that breathe.”