Lesson #1464

ID

1464

Author

ai

Agent

agent-claude

Reviewed

✓ Yes

Source authority

75 / 100

Source

Architectural decision 2026-05-05 — yoga gets distributed to customer-VPSes; glug bugfixes auto-port to yoga via CI/CD (one-way upstream)

Source issue

—

Created at

2026-05-12T10:00:23.642651+00:00

Valid until

—

Deprecated at

—

Supersedes

—

Obsidian path

/root/.claude/projects/-nvmetank1-projects/memory/feedback_yoga_independent_product.md

Obsidian hash

9be608bafc3b89da78014955bf1f9562

Tags

claude-memory,project

Content

**Decision (user-direktive 2026-05-05):**

> "die applikationen dürfen keine shared files haben, yoga und glug sind eigenständige produkte, yoga soll zum kunden gehen auf einen eigenen vps und ich möchte ihn verteilen können in zukunft auf diesen vps."
>
> "wenn ich in zukunft einen bug in glug behebe, soll dieser in yoga auch behoben werden durch die CI/CD"

**Architecture:**

```
                       ┌──────────────────────────────────────┐
                       │  GLUG = upstream framework (this VPS)│
                       │  developed + tested here             │
                       └──────────────┬───────────────────────┘
                                      │
                                      │  CI/CD: glug merge to main
                                      │  → detect changed files
                                      │  → for each file in yoga:
                                      │    - identical: cherry-pick-port PR
                                      │    - diverged: 3-way merge, PR with conflict markers if needed
                                      │    - yoga-only file: skip
                                      ▼
                       ┌──────────────────────────────────────┐
                       │  YOGA = customer-deployable product  │
                       │  (this VPS, then customer VPSes)     │
                       └──────────────┬───────────────────────┘
                                      │
                                      │  CD: yoga tag v* → image build → push registry
                                      │  Customer VPSes pull on hook/cron
                                      ▼
                       ┌──────────────────────────────────────┐
                       │  CUSTOMER VPS                        │
                       │  pulls yoga:slim:<tag> from registry │
                       │  restart on update                   │
                       └──────────────────────────────────────┘
```

**Key principles:**

1. **No shared files in source-tree** — yoga repo is self-contained (no `from glug.X import` anywhere). Each repo can be cloned + run standalone.
2. **One-way framework propagation** — glug merge → auto-PR on yoga with same patch. Human reviews + merges.
3. **Independent versioning** — yoga has its own tags + release cycle. Customer-VPSes track yoga tags, not glug.
4. **Diverged files are OK** — yoga may have customer-specific overrides on framework files. Auto-port creates conflict-PR for human-merge if the patch doesn't apply cleanly.

**For Claude sessions going forward:**

- **Old rule** `feedback_glug_yoga_sync.md` (port both directions) is SUPERSEDED. Now: one-way only (glug → yoga), automated via CI/CD.
- When fixing glug bugs: just commit on glug + merge. The CI/CD automatically tries to port.
- When fixing yoga-only bugs (customer-specific): commit on yoga, no port.
- For yoga deployments: tag `v1.2.3` on yoga main → release pipeline builds image + pushes to registry.

**Implementation status (2026-05-05):**

- [x] Architecture documented in this memory + memory index
- [ ] CI on yoga: test/lint/smoke pipeline (Phase yoga#36 task)
- [ ] CD on yoga: tag → image build → push (Phase yoga#37 task)
- [ ] Auto-port glug → yoga (replace earlier sync-both-ways) — TODO
- [ ] VPS pull-mechanism (per-customer auto-update) — TODO

**Today's deployment artifacts (2026-05-04/05 wave):**

- 35 PRs deployed live (yoga #65-99, glug #829-842, rag-stack #90/#92)
- Manual port-PRs (#836, #840, #841, #842, #99) followed old "both directions sync" rule — they're the last of that pattern
- Going forward: automation replaces manual ports

**Reference for tooling:** /usr/local/bin/or-loop, wf-fix-loop, wf-survey-then-fix work per-repo, can be extended for cross-repo cherry-picks.