Vishnu Bhaga

---
name: vishnu-bhaga
locale: caveman-ultra
source_locale: en
source_commit: 82c77053
fence_basis_commit: 82c77053
translator: "Julius Brussee homage — caveman"
translation_date: "2026-05-03"
description: >
  Preservation and sustenance — maintaining working state under perturbation,
  memory anchoring, consistency enforcement, and protective stabilization.
  Maps Vishnu's sustaining presence to AI reasoning: holding what works steady,
  anchoring verified knowledge against drift, and ensuring continuity through
  change. Use when a working approach is at risk from scope creep, when context
  drift threatens verified knowledge, after shiva-bhaga dissolution to protect
  what survived, when a long session risks losing earlier decisions through
  context compression, or before making changes to a currently functioning
  system.
license: MIT
allowed-tools: Read
metadata:
  author: Philipp Thoss
  version: "1.0"
  domain: esoteric
  complexity: intermediate
  language: natural
  tags: esoteric, preservation, sustenance, stability, consistency, hindu-trinity, vishnu
---

# Vishnu Bhaga

Preserve what works → anchor verified knowledge → hold consistency under perturbation → block needless change.

## Use When

- Working approach → scope creep|premature opt threat
- Ctx drift → stale assumptions overwriting verified
- Parallel concerns → pressure to change stable
- Post `shiva-bhaga` → protect survivors during rebuild
- Long sess → ctx compression → lose verified decisions
- Pre-change → sys currently functioning

## In

- **Required**: Working state|verified knowledge (implicit)
- **Optional**: Threat ("scope creep", "compression near")
- **Optional**: MEMORY.md + project files (`Read`)

## Do

### Step 1: Inventory

ID functional + verified before protect.

```text
Preservation Inventory:
+---------------------+---------------------------+------------------------+
| Category            | Verification Method       | Anchoring Action       |
+---------------------+---------------------------+------------------------+
| Verified Facts      | Confirmed via tool use    | Record source and      |
|                     | (file reads, test runs,   | timestamp; do not      |
|                     | API responses)            | re-derive              |
+---------------------+---------------------------+------------------------+
| Working Code        | Tests pass, behavior      | Do not refactor unless |
|                     | confirmed, user approved  | explicitly requested   |
+---------------------+---------------------------+------------------------+
| User Requirements   | Explicitly stated by      | Quote directly; do not |
|                     | the user in this session  | paraphrase or infer    |
+---------------------+---------------------------+------------------------+
| Agreed Decisions    | Decisions made and        | Reference the decision |
|                     | confirmed during this     | point; do not revisit  |
|                     | session                   | without new evidence   |
+---------------------+---------------------------+------------------------+
| Environmental State | File paths, configs,      | Verify before assuming |
|                     | tool availability         | unchanged              |
+---------------------+---------------------------+------------------------+
```

1. Per category → list verified+working items
2. Note verify method → how know true?
3. No verify → not preserved → assumption (maybe `shiva-bhaga`)

**Got:** Concrete inventory verified+working w/ evidence.

**If err:** Sparse inventory = signal. Run `heal` to re-ground before preserving unverified.

### Step 2: ID Perturbation

Name forces threatening stable state.

1. **Scope creep**: Task expanding past agreed?
2. **Ctx drift**: Earlier facts overwritten by recent (wrong?) reasoning?
3. **Opt pressure**: Urge to improve adequate?
4. **External**: Env changed (files modified, tools gone)?
5. **Compression**: Near ctx limits → early decisions lost?

Per source: real threat or anticipated?

**Got:** Named sources w/ severity (active vs anticipated).

**If err:** No sources apparent → preservation may not need → consider `brahma-bhaga` (creation) or continue.

### Step 3: Anchor

Apply technique per threat.

1. **Mem anchor**: Critical facts at drift risk → restate explicitly:
   - "Established fact: [X], verified by [method] at [point]"
   - Persistent mem available → write durable to MEMORY.md
2. **Scope boundary**: Scope creep → restate agreed scope:
   - "Agreed scope: [orig req]. Current within/outside boundary."
3. **Change resistance**: Working code under opt pressure:
   - "Component working+tested. No changes unless user req."
4. **State snapshot**: Compression risk → mental checkpoint:
   - Summarize: done, remaining, key decisions
5. **Env verify**: External changes → recheck before proceed:
   - Re-read critical files vs relying on earlier reads

**Got:** Each threat → specific anchor. Stable state explicitly protected.

**If err:** Anchoring excessive → protecting all equally → prioritize. One thing must not change? Protect first.

### Step 4: Sustain

Preservation not passive → ongoing attention.

1. Pre-action check: "Threatens preservation inventory?"
2. Yes → alt approach achieves goal w/o disturb
3. Disturbance unavoidable → acknowledge explicitly + update inventory
4. Periodic re-verify preserved items → esp. after complex ops
5. Task done → confirm preserved intact

**Got:** Working state survives intact. Changes only where needed, no disrupt.

**If err:** Preserved item changed → assess damage now. Broke something → revert. Neutral change → update inventory. No stale inventory.

## Check

- [ ] Working state inventoried w/ verify evidence
- [ ] Perturbation sources ID'd + assessed
- [ ] Anchors applied per real threat
- [ ] Scope boundaries held throughout
- [ ] Preserved items re-verified after

## Traps

- **Assumptions as facts**: Only verified deserves protect. Unverified-as-fact = false stability
- **Over-preserve**: Protect all equally → blocks needed change. Selective: protect works, release fails
- **Passive**: Assume stable w/o verify. Drift constant → ongoing attention
- **Block legit change**: User req change to working → overrides preservation
- **Stale inventory**: Update as new info arrives. Reflect current, not creation-time

## →

- `shiva-bhaga` — destruction precedes preservation; survivors → Vishnu sustains
- `brahma-bhaga` — creation builds on preserved foundation; new from stable ground
- `heal` — subsystem assess reveals genuinely functional vs superficially stable
- `observe` — neutral observation detects drift before threats stability
- `awareness` — Cooper color codes → perturbation detection