opentsc

name

opentsc

description

OpenTSC v2.1: Soul/Shell architecture for interpersonal intelligence. Local, offline-first, with event graphs, judgment engine (K7), self-creation (K8), three-layer attributes, calibrated predictions, 11 VSM professions, and a pluggable zvec memory index (semantic search, identity resolution, jieba segmentation, emotion scoring incl. batched+cached LLM) that runs with zero extra deps. Transforms implicit social judgment into explicit, queryable, auditable, evolving intelligence.

OpenTSC v2.1 Skill — Soul/Shell Architecture

Use this skill when the user wants to design, build, review, or operate OpenTSC: a single-user, local/offline-first interpersonal intelligence system derived from the TSC doctrine.

OpenTSC turns implicit social judgment into explicit, queryable, auditable, evolving structure. It is a private intelligence and operations system — a personal war room — not a CRM.

The Twelve Laws (non-negotiable)

Existence

1. Genesis immutable — a TSC's reason for existence is set once, never changed.
2. Soul/Shell separation — law+memory (soul) survives shell replacement. Export soul/ = export the TSC.
3. Identity by ID — stable IDs, never name-anchored paths.

Perception

4. Append-only events — intelligence is a stream; current state is derived.
5. Evidence before judgment — Admiralty rating + source on every event; reasoning chain + due date on every prediction.
6. Draft before registry — auto-extraction → inbox/; formal entry needs user confirmation.

Judgment

7. Dual codex — rule codex (what's allowed) + judgment codex (what's good/trustworthy/worth mobilizing).
8. Reality calibrates, not comfort — prediction outcomes drive learning; comfort feedback is recorded but never tunes generation.
9. Attributes from events, not hand-filled — K7 derives attributes via judgment_codex. No direct writes.

Evolution

10. Grow only where needed — minimum viable structure; new agents/skills only on proven gaps.
11. Four-fold self-creation — rules, agents, goals, boundaries can all self-generate through governed processes.
12. Recursive isomorphism — person/team/org/ecosystem use the same cycle and attribute ontology.

If an instruction conflicts with these laws, stop and ask.

Architecture

Soul (portable)          Shell (replaceable)        World (entities)
├── _genesis.md          ├── kernel/ (K1-K8)        ├── players/
├── _rule_codex.md       ├── modules/ (Agent Skills) ├── npcs/humans/
├── _judgment_codex.md   ├── professions/ (11 VSM)  ├── npcs/agents/
├── _schema.md           └── genesis_engine/        ├── orgs/
├── events/ (graph)                                 └── operations/
└── calibration/

Key Capabilities (v1.0)

Event Graph (K3)

Events are independent nodes in soul/events/, linked to multiple entities and to each other via causal edges. Query by entity, date, admiralty. Compute full neighborhood graphs.

Judgment Engine (K7) — core innovation

When an event arrives, K7 reads judgment_codex and auto-derives attribute patches. Three-layer attributes:

• Base (innate, slow-changing): execution_ceiling, learning_speed, resilience, reliability, autonomy
• Skills (event-driven levels): negotiation Lv.3, client_psych Lv.5, etc.
• States (temporary buff/debuff with expiry): "已读不回·可靠性存疑" debuff, 7-day countdown

Every attribute is an AttributeClaim: {value, confidence, provenance, reviewed, decay, source_admiralty}.

Direct Comparison

judgment-compare p_alice p_bob negotiation → answers "who is stronger" without re-reading all history.

Self-Creation Engine (K8)

Detects VSM capability gaps, generates Agent Skill drafts, validates against laws, requires player approval to activate.

11 Professions (VSM-complete)

founder, commander, sentinel, ingestor, distiller, oracle, herald, coordinator, operator, steward, recruiter.

Calibration Loop

Predictions with due dates → outcome tracking → hit rate stats → judgment codex self-iteration.

Memory & Determinism (v2.0)

The vault markdown is the source of truth; a derived, rebuildable zvec memory index (under soul/.index/) gives semantic search, hybrid retrieval, and identity resolution. Everything is pluggable and degrades gracefully:

• Embedding backend (lite | local | api) and emotion backend (lexicon | model | llm) are chosen in soul/_config.yaml. The core runs with zero extra dependencies — lite hashing vectors, a built-in emotion lexicon, and a regex segmenter are always available; jieba / snownlp / zvec / on-device models are opt-in (see requirements.txt).
• Semantic recall replaces full-vault re-reads: index-search, identity-resolve (kills hash-id sprawl and name drift), index-sync.
• Deterministic precompute replaces token-burning LLM scans: emotion-score, text-segment, actions-stale. Compute facts in Python; spend the LLM only on judgment.

The CLI-first mandate (non-negotiable)

Scope first — this does NOT make the agent robotic. Understanding the user's natural-language intent is, and remains, the agent's job: read the request, infer what is meant, then route to the right command(s). The mandate governs execution, not understanding. Use index-search as your semantic recall — turn a fuzzy human ask ("谁最近在交付上靠谱？") into a query against the index instead of a brittle keyword scan, and fall back to reading specific files only when no command fits. Free-text intake stays LLM-driven (capture-actions, draft-inbox-event, suggest-actions).

What the mandate forbids is wasting the LLM on mechanical work a command already does. The agent must not hand-read or hand-write vault files for anything a command covers. Reading every markdown file to count, find, segment, score sentiment, or resolve a name is both a token furnace and the root cause of drift (wrong counts, 马克思 vs 马斯克, corrupted YAML). Instead:

• Never hand-write YAML frontmatter — always go through the CLI writers.
• Never re-scan the vault to find or count — use index-search, actions, actions-stale, timeline, due.
• Never guess identity — use identity-resolve before creating an entity.
• Data sources (WeChat, email, transcripts) are not core — they are user-built skills that feed the CLI. See references/extending-with-skills.md.

Skill workflow

When working on OpenTSC:

1. Classify the request. Is it soul, shell, world, event, judgment, profession, genesis, or legacy operation?
2. Load only the needed reference module. Keep context small and modular.
3. Preserve laws first. Refuse shortcuts that bypass stable IDs, append-only events, evidence ratings, feedback due dates, or user confirmation gates.
4. Prefer a command over reading files. If a CLI command can answer it deterministically, call it — do not re-scan the vault (CLI-first mandate above).
5. Use v1 commands for v1 vaults. Check is_v1_vault(root) and route accordingly.
6. Make drafts explicit. Automatic extraction → inbox/; formal entry requires user confirmation.
7. Return auditable outputs. Include IDs, source references, reasoning chains, confidence, and next decisions.

Module map

• scripts/opentsc.py — CLI with v1.0 commands (soul-, world-, event-, judgment-, profession-, genesis-, schema-*) + full legacy backward compat
• scripts/opentsc_core/ — modular Python implementation:
  • soul.py — genesis, codex, export/import
  • events.py — K3 event graph engine
  • judgment.py — K7 judgment engine (core innovation)
  • world.py — entity creation (players, NPCs, orgs, operations)
  • identity.py — K1 ID service, aliases, dedup
  • professions.py — 11 VSM profession definitions
  • genesis_engine.py — K8 self-creation engine
  • schema_mgr.py — K5 field ontology
  • migrate.py — v0.4 → v1.0 vault migration
  • common.py — shared utilities, path helpers, YAML frontmatter
  • v2.0 config.py — pluggable backend selection (embedding/emotion)
  • v2.0 text.py — jieba segmentation + keywords (regex fallback)
  • v2.0 emotion.py — pluggable sentiment (lexicon/model/llm)
  • v2.0 embedding.py — pluggable vectors (lite/local/api)
  • v2.0 index.py — zvec memory index (markdown stays source of truth)
  • vault.py, entities.py, relations.py, query.py, actions.py, calibration.py, filing.py, sources.py, contacts.py, conflicts.py, report.py, validate.py, upgrade.py, skills.py — legacy modules (enhanced for v1.0 compat)
• references/philosophy.md — Twelve Laws
• references/data-contract.md — soul/shell/world layout, event graph schema, AttributeClaim
• references/kernel.md — K1-K8 responsibilities and API
• references/plugins.md — module families and contracts
• references/extending-with-skills.md — how data-source skills (WeChat, email, …) feed the core
• requirements.txt — optional dependencies per backend
• templates/ — person_v1, event, profession, genesis_seed, judgment_codex_seed, rule_codex_seed, + legacy templates

CLI command groups

soul-init, soul-export, soul-import, soul-genesis, soul-codex, soul-amend
world-new-player, world-new-npc, world-new-org, world-new-operation
event-add, event-link, event-cause, event-read, event-timeline, event-neighborhood
judgment-attribute, judgment-compare, judgment-explain, judgment-decay, judgment-clean-states
profession-list, profession-gaps, profession-assign, profession-init
genesis-detect-gaps, genesis-spawn, genesis-validate, genesis-register, genesis-sunset
schema-list, schema-register, schema-validate
migrate
index-build, index-sync, index-search, identity-resolve, index-stats   (v2.0 memory)
emotion-score, text-segment, actions-stale, config-show                (v2.0 deterministic)
+ all legacy commands (init, new-person, add-event, query, who-can, link, etc.)

Default output style

For design or implementation answers:

## Classification
<soul | shell | world | event | judgment | profession | genesis | legacy>

## Applicable laws
- ...

## Minimal design
- ...

## Extension points
- ...

## User decisions needed
- ...

For generated OpenTSC records, never invent missing evidence. Use TODO(user) for facts the user must supply.