Metadata-Version: 2.4
Name: chlang
Version: 3.17.0
Summary: φ-lang v6 + φC engine: chess-identity capability library — pure-C engine + native C browser, white-label Raman agent, chained audit
Author: Cerie Raman
License: MIT
Keywords: phi-lang,chess,capability,engine,philang
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: C
Classifier: Topic :: Software Development :: Libraries
Requires-Python: >=3.8
Description-Content-Type: text/markdown
Requires-Dist: python-chess>=1.999

# chlang v3 — pure C, three folders, flat files

**Pure C. No Python. No runtime. One engine.** Every script carries its own
**capability vector** (7 numbers: compute/data/network/security/math/media/
learning) + **KV self-lookup** (`kv_lookup("name")`) for direct addressing.

## The structure — three folders, flat files

```
chlang/
├── setup/          ← 12 flat files, everything required to work
│   ├── chlang.c            the engine
│   ├── Makefile            build
│   ├── fen_index.json      the SMALL FEN dictionary (8 KB)
│   ├── atom_table.c        φ-lang v6 atoms (16,237)
│   ├── skill_table.c       skills (10,292)
│   ├── phrase_table.c      phrases (10,292)
│   ├── content_table.c     content bodies (10,292)
│   ├── class_table.c       membrane classes (11)
│   ├── meta_table.c        version chain, refcounts, genesis
│   ├── capability_table.c  phi-v6 tournament winners (35) — winner|elo|sigma|fen
│   ├── brain_db.c          calibration DB (compressed embed)
│   └── README.md
├── c_library/      ← ONLY the 171 callable C scripts
│   ├── 00_data/ 01_deploy/ ... 12_youtube/  (13 folders)
└── c_phrases/      ← projects (.md + FEN + direct calls)
    ├── sms_security_platform/
    └── youtube_ingest/
```

## Build

```bash
cd setup
make
./chlang            # the whole system
./chlang cap MATH   # class -> FEN -> range -> folder + capability vector
./chlang capability SORT   # tournament winner (winner|elo|sigma|fen|moves|atoms)
./chlang_arch       # tensor search over 171 real scripts + diamond lattice
./board_builder sms_security_platform   # deterministic 64-block board config
./board_builder youtube_ingest full     # all 64 blocks (free blocks shown)
```

## Every script is addressable two ways

1. **KV self-lookup** — `kv_lookup("name")` returns the script's role.
2. **Capability vector** — `vector()` returns its 7-number vector
   {compute,data,network,security,math,media,learning}; the dictionary
   (`fen_index.json`, `chlang.c` CAPS) carries the same vector per class, so
   tensor search (`chlang_arch.c`, cosine similarity) matches by MEANING —
   the right script is found even when the query shares no words with its name.

## Boards — deterministic config (the ONLY file you edit)

`board_config.c` declares each project's 64-block board: the script list that
fills the 60 compute blocks (a1..h8 minus corners). The 4 corners (a1/h1/a8/
h8) are always NETWORK ports — they bond to other boards in the cube
(carbon-atom model: 6 faces per cube, 64 cubes per board, corner cubes bond
board-to-board). `board_builder.c` resolves every script to its real file
(hard error if missing), wires the blocks, fingerprints the board as a FEN
(deterministic hash of the sorted script list: same config = same FEN
forever, any change = different FEN), assigns the membrane (class →
dictionary range), and prints the cube formation.

## The scale (Shiv's hierarchy)

```
block       = 1 square = 1 C script call
board       = 8x8 = 64 blocks (a 2D FEN board)
block cube  = 6 blocks (6 faces)
board cube  = 8x8x8 = 512 block cubes = 3072 blocks
            = 3072 C script calls + its 6 FEN configs (one per face)
crystal     = 1000 board cubes = 3,072,000 C calls
lattice     = 1000 crystals   = 3,072,000,000 C calls
half brick  = 500 lattices    = 1,536,000,000,000 C calls
full brick  = 1000 lattices   = 3,072,000,000,000 = 3.072 TRILLION C steps
```

## Raman gap set (v3.7.0 → v3.8.0: REAL C implementations)

25 capability scripts so a full agent (Raman-class) board can be built:
`14_browser/` (10: navigate/snapshot/click/type/scroll/back/console/press/
get_images/vision), `15_web/` (search/extract), `16_exec/` (terminal/process/
code), `17_memory/` (store/session_search), `18_schedule/` (cron),
`19_interface/` (clarify/tts/vision), plus 4 file ops in `02_file/`
(read/write/patch/search).

**v3.8.0: every one is a REAL C program, not a white label.** Each does actual
work when called: file read/write/patch/search via real fd I/O, exec via
fork/popen (verified: `exec_code` returns real Python output), web via a real
socket HTTP client (URL-encoded GET + result/HTML parsing), memory via an
append-only on-disk KV store, cron via a persistent job registry, tts via real
16-bit PCM WAV synthesis (RIFF-verified), vision via real PNG/JPEG/PPM header
parsing + entropy, browser via real HTTP fetch + HTML parsing + CDP JSON
commands emitted to a live Chrome DevTools port when reachable (graceful
degradation: command string returned otherwise). No personal data embedded.
The `raman` board project fills all 60 compute blocks (25 new + 35 shared).

## Storage home + audit trail (v3.9.0)

All data lives under **`$CHLANG_HOME`** (default `~/.chlang/`) — never /tmp:

```
~/.chlang/
├── memory.kv          append-only key:value memory store
├── jobs.txt           scheduled job registry
├── state/             page.html (browser), tts.wav (synthesis)
└── log/audit.log      EVERY fire: ts|script|action|result
```

Every script's `run()` appends one line to `log/audit.log` (O_APPEND,
parallel-safe) — nothing fires silently. Read the ledger:

```bash
./chlang state            # audit tail + memory + jobs
./chlang state audit      # just what fired (last 50)
./chlang state memory     # what's stored
./chlang state jobs       # scheduled jobs
```

`20_state/state_ledger.c` is itself a library script (VEC + KV + run) —
the "know what happened" capability is part of the library, not bolted on.

## The data files — what each is FOR

| file | what it is |
|------|-----------|
| `atom_table.c` | φ-lang v6 word→atom (16,237) — encode |
| `skill_table.c` | 10,292 skills — what exists |
| `phrase_table.c` | 10,292 phrase codes → skills |
| `content_table.c` | 10,292 content bodies — the knowledge |
| `class_table.c` | 11 membrane class definitions |
| `meta_table.c` | version history + registry state |
| `capability_table.c` | 35 tournament winners (class → winner\|elo\|sigma\|pawn\|FEN\|moves\|atoms) |
| `brain_db.c` | calibration SQLite DB (compressed, write_db() restores) |

All are the SAME pattern (KV table + lookup). New info = new table
body only. brain_db.c is optional — delete it if calibration data
isn't needed.

## The chain (v3.10.0) — every fire, traceable two ways

Every script's `run()` appends to `~/.chlang/log/chain.log`:

```
ts|sha256|prev_sha|script|loc|action|result
```

- `sha256` = hash of (ts|prev_sha|script|loc|action|result) — each entry
  links to the previous: tamper-evident, blockchain-style (but part of the
  system, no external chain).
- `loc` = `$CHLANG_LOC` = **brick.lattice.crystal.boardcube.board.block**
  (default `0.0.0.0.0.standalone`). The board runner sets it per block, so
  every fire knows exactly where it happened — up to the brick.
- Two-way: chain → forest (`chlang state chain`/`verify`), structure →
  history (`chlang state loc:...` / `script:...`).

```bash
./chlang state chain        # last 50 fires, where they happened
./chlang state verify       # recompute every sha + link (tamper check)
./chlang state loc:0.0.0.0.0.b1    # history of one block
./chlang state script:memory_store # all fires of one script
```

## Skill tools + todo + delegate (v3.11.0)

- `21_skills/skills_list.c` — the **dictionary of known best configurations**:
  tournament winners (proven best per class) + every library domain with
  script counts. `./skills_list`
- `21_skills/skill_view.c` — resolution chain: **phrase → membrane → dictionary
  → folder** (the direct configuration), or **CLASS → dictionary**, or **direct
  search** across the whole library, or keyword fallback. `./skill_view <name>`
- `22_todo/todo.c` — persistent task list at `~/.chlang/todo.txt`:
  `list | add|<text> | start|<id> | done|<id> | del|<id>`
- `23_agent/delegate_task.c` — spawn a subagent **from existing scripts**:
  finds the script in the library, compiles it to `~/.chlang/build/`, runs it
  as a child process, stores the result in `memory.kv`, audits the chain.
  `task|scriptname[|arg]` or `task|@shell-command`

All four: VEC[7] + KV + run() + chained audit. Dictionary now 23 classes.

## Common doc — understand anything (v3.12.0)

The library holds scripts in ANY language (`24_doc/` ships `common_doc.c` +
`python_network_probe.py` — a real Python socket probe). When a block runs a
script at any scale up to a brick, its documentation lands in ONE file:

```
~/.chlang/docs/common.md — read this to understand anything
```

- `./chlang doc read` / `read|<name>` — read it
- `./chlang doc ingest|<name>` — extract one script's doc (language-aware:
  C header, Python docstring, shell comments, JS, JSON, φ)
- `./chlang doc ingest-all` — rebuild the whole runnable library into it
- `delegate_task` auto-ingests the doc of every script it runs — so any
  fire, any language, documents itself into the common doc automatically

`common_doc` is on the raman board (60/60). Dictionary: 25 classes.

## consume — the gap check (v3.13.0)

`./chlang consume "capA,capB,..."` checks a new system's capability list
against the current library and reports the GAP (present vs missing).
The consume loop: check → add missing as scripts (white-label → real C,
VEC + KV + run + chain) → FEN-coded board config → membrane (class → range
→ folder) → c phrase. Raman toolset today: 30 present, 0 missing, gap ZERO.

## raman chat (v3.14.0)

`./chlang chat "message"` or interactive `raman_chat`: routes messages to
board blocks (read/write/search/run/remember/recall/todo/skills/doc/state/
consume/probe), fires them, replies with real C output, audits the chain
twice (block run + chat routing).
