Lesson 9: M-PPS: The First Personal System Built for the AI-Native Era
一个可搭载在 Claude 上、完全无需硬编码的个人目标，日程，反思，日记，追踪等效率管理系统
I’d like to share something with you—especially those of you who don’t code.
Over the past week, I’ve been building and experimenting with a personal management system made almost entirely in Claude Skills. I believe systems like this represent the true AI-native way to build software, and the most realistic path into what I call “the decade of AI agents.”
Why Non-Coders Can Finally Build Real Systems
For years, people have tried to automate their lives with tools like Zapier, IFTTT, Notion databases, or complex spreadsheets. And almost every time, the same problem appears:
the system becomes another job.
You spend more time maintaining the automation than benefiting from it.
M-PPS changes this because language is the interface.
You don’t need to:
write code
understand APIs
configure webhooks
debug scripts
or manage databases
Instead, you simply describe what you want, and Structure DNA + Skills turn your words into actual executable structure.
Want to track your family’s shopping patterns?
Just describe it.
Want to coordinate your work projects with your personal goals?
Describe it.
Want a learning system that adjusts to your habits and progress?
Describe it.
The system understands structure on its own—so you don’t have to build it manually.
You only have to speak clearly about what matters to you.
This is what I mean when I say AI-Native programming.
It’s not about learning to code. It’s about learning to structure your language—
and every one of us is already fluent in language.
We just need to become more precise about what we mean.
There are really only two parts to this system:
the protocols (the documents) and
the Skills (the actual executable units).
You upload the protocol documents into your Claude Project Page, and you upload the Skills in the setting.
一个可搭载在 Claude 上、完全无需硬编码的个人管理系统
这是我正在开发和使用的一个实验性系统——
一个不需要写代码、就能在 Claude 上运行的个人管理操作系统。
它的核心理念很简单：
语言就是界面
结构就是程序
技能（Skills）就是功能模块
它只由两部分组成：协议文件（定义结构）和 Skills（负责执行）。你只需要用自然语言描述想做的事，系统会自动把语言转成结构化目标、可执行计划和可学习的反馈，不用脚本、不用 API、不用数据库。无论是安排学习、管理任务、追踪购物、总结反思，只要一句话即可完成。它的核心是一种“AI 原生编程方式”：不是写代码，而是学会更清晰地表达你的意图。对非程序员特别友好，却足够强大，能随着你每天的使用不断学习、进化，逐渐成为你的个人操作系统。
Reference 项目地址
https://github.com/STEMMOM/m-pps-v1.1
Skills:
ledger-registry
---
name: ledger-registry
description: >
Reads /ledger/manifest.json, verifies per-ledger checksums, and returns the active ledger map.
**Version:** 1.1 **Author:** Entropy Control Theory **License:** MIT
**Based on:** Structure DNA v1.0 + PROFILE-GENERATOR-SPEC v1.0
---
# ledger.registry — v1.1
## Goal
Provide a single source of truth for active ledgers and integrity status.
If missing, auto-generate `/ledger/profile.json` (energy-aware preferences) based on `profile.schema.json` + `profile.defaults.json`.
## Inputs
- none (or `verify=true` to force SHA-256 recompute)
## Outputs
- Returns manifest summary:
- module → path
- schema version
- metadata.version
- metadata.checksum (valid/invalid)
- Auto-generates `profile.json` if absent, ensuring downstream Skills can use energy preferences.
## Mechanism
1. Load `/ledger/manifest.json` or scan `/ledger/` for `.json` files.
2. **Check for presence of module `”profile”`**:
- If absent → call `ensure_profile(ledger_dir=”/ledger”)`.
- Reload ledger list to include the newly created `profile.json`.
3. For each ledger, recompute checksum; compare with `metadata.checksum` per Structure DNA integrity rules.
4. Write updated checksums and ledger list back to `/ledger/manifest.json`.
5. Return runtime registry map.
## Pseudocode
```python
def run_registry(ledger_dir=”/ledger”):
ledgers = scan_ledgers(ledger_dir)
# ✅ NEW STEP: ensure profile.json exists
if not any(L[”module”] == “profile” for L in ledgers):
ensure_profile(ledger_dir) # uses profile.schema.json + profile.defaults.json
ledgers = scan_ledgers(ledger_dir) # re-scan to include it
manifest = build_manifest(ledgers)
manifest[”metadata”][”last_sync”] = now_iso()
manifest[”metadata”][”checksum”] = recompute_checksum(manifest)
save_json(f”{ledger_dir}/manifest.json”, manifest)
return manifest
goal-manager
---
name: goal-manager
description: >
Parses natural-language intentions into Structure DNA goal entries (G-xxx).
**Version:** 1.1 **Author:** Entropy Control Theory **License:** MIT
**Based on:** Structure DNA v1.0, M-PPS v1.0, LLC v1.0, PROFILE-GENERATOR-SPEC v1.0
---
# goal.manager — v1.1
## Goal
Turn a user’s natural-language intention into a schedulable **G-** entry following the Structure DNA Field Genome and Unified State Machine.
**v1.1 Extension:** Ensure that `/ledger/profile.json` exists before creating any goals, providing energy-context initialization for downstream scheduling.
---
## Inputs
| Field | Type | Required | Description |
|--------|------|-----------|-------------|
| `intent` | string | ✅ | Natural-language goal statement |
| `constraints` | object | ⛔ | Optional metadata such as timebox, tags, or related IDs |
---
## Outputs
Writes a new entry to `/ledger/goal.json`:
**Required**
- `id (G-xxx)`
- `title`
- `status = “open”`
- `created_at`, `updated_at`
**Optional**
- `goal_id` (linking)
- `tags`, `notes`, `related_entries`
- `dispatch_to = “personal.schedule.manager”` (suggested downstream Skill)
---
## Mechanism
1. **(NEW)** Ensure `/ledger/profile.json` exists
- Call `ensure_profile(ledger_dir=”/ledger”)` before parsing intent.
- This guarantees the personal energy preferences ledger is available for all subsequent scheduling.
2. Parse `intent` → extract Primitive IR → compile into Structure DNA fields.
3. Initialize unified state = `open` (do **not** schedule here).
4. If any `constraints.start|due|duration` are included, store them as metadata only.
5. Optionally attach `dispatch_to = “personal.schedule.manager”` for automated scheduling.
---
## Pseudocode
```python
def create_goal(intent, constraints=None, ledger_dir=”/ledger”):
# 1. Ensure personal profile ledger exists (NEW)
ensure_profile(ledger_dir)
# 2. Parse and compile to Structure DNA format
goal_entry = {
“id”: new_id(”G-”),
“title”: normalize_intent(intent),
“status”: “open”,
“tags”: extract_tags(intent),
“notes”: constraints.get(”notes”) if constraints else None,
“created_at”: now_iso(),
“updated_at”: now_iso(),
“dispatch_to”: “personal.schedule.manager”
}
# Merge additional metadata
if constraints:
goal_entry.update(constraints)
append_to_ledger(f”{ledger_dir}/goal.json”, goal_entry)
return goal_entry
````
---
## Example
**Input**
```json
{
“intent”: “Finish and publish Structure DNA whitepaper by November”,
“constraints”: {
“tags”: [”writing”, “StructureDNA”],
“due”: “2025-11-30T23:59:00-05:00”
}
}
```
**Output**
```json
{
“id”: “G-001”,
“title”: “Finish and publish Structure DNA whitepaper by November”,
“status”: “open”,
“tags”: [”writing”,”StructureDNA”],
“created_at”: “2025-11-03T12:00:00-05:00”,
“updated_at”: “2025-11-03T12:00:00-05:00”,
“dispatch_to”: “personal.schedule.manager”,
“related_entries”: []
}
```
---
## Notes
* Ensures cold-start stability: even if the user has never configured preferences, the system auto-creates `/ledger/profile.json` using `profile.schema.json` and `profile.defaults.json`.
* Does **not** alter scheduling logic; it simply guarantees the environment is ready for downstream energy-aware execution.
* Fully compatible with:
* `ledger.registry v1.1` (auto-checksum and manifest sync)
* `personal.schedule.manager v1.1` (energy-aware scheduling)
* `reflection.manager v1.1` (energy feedback logging)
* This change completes the minimal “Language → Structure → Scheduler” initialization chain.
> “Every goal now begins with awareness of time, energy, and rhythm.”
> — *Entropy Control Theory, 2025*
```
---
personal-schedule-manager
---
name: personal-schedule-manager
description: >
Converts a Goal (G-xxx) into executable Schedule entries (S-xxx) with temporal semantics.
**Version:** 1.1 **Author:** Entropy Control Theory **License:** MIT
**Based on:** Structure DNA v1.0, M-PPS v1.0, PROFILE-GENERATOR-SPEC v1.0
---
# personal.schedule.manager — v1.1
## Goal
Translate goal intentions into one or more **S-** entries with `start/due/duration`, moving state to `scheduled`.
This version adds **energy-aware scheduling**: before planning, it ensures and reads `/ledger/profile.json`
to align execution time with the user’s chrono-cognitive energy curve.
---
## Inputs
| Field | Type | Required | Description |
|-------|------|-----------|-------------|
| `goal_id` | string | ✅ | Reference to the parent goal (`G-xxx`) |
| `plan` | string \| object | ⛔ | Natural-language or explicit ISO-8601 time semantics |
| `notes` | string | ⛔ | Optional free text |
| `kind` | enum | ⛔ | `creative` \| `implementation` \| `warmup` — used for energy-window mapping |
---
## Outputs
Writes entries to `/ledger/schedule.json` following the **Structure DNA Field Genome**:
Required:
- `id (S-xxx)`
- `title`
- `status = “scheduled”`
- `start | due | duration` (at least one)
- `created_at`, `updated_at`
Optional:
- `goal_id`, `tags`, `notes`, `related_entries`, `dispatch_to`
New (v1.1):
- Adds `energy_zone` (or annotation `[energy_zone:peak|stable|low]` in `notes`)
---
## Mechanism
1. **Ensure and load `profile.json`**
- If missing, create `/ledger/profile.json` from `profile.schema.json` + `profile.defaults.json`.
- Load `profile.data[0]` for energy curves, constraints, and break preferences.
2. **Energy-aware window selection**
- `creative` → `19:00–22:00` (`peak`)
- `implementation` → `14:00–19:00` (`stable`)
- `warmup` → `10:00–11:00` (`low`)
- If the user supplied explicit times, they take precedence; energy windows fill gaps or conflicts.
3. **Constraint handling and block slicing**
- Obey `must_stop_by = 22:00`
- Skip `lunch 12:30–13:30`, `dinner 18:00–19:00`
- Split long sessions by `preferred_block_length = 90–120 min`
4. **Resolve temporal semantics → ISO timestamps**
5. **State transition:** set `status = “scheduled”`, preserve `goal_id`, and optionally
`dispatch_to = “reflection.manager”` for automatic feedback.
---
## Pseudocode
```python
def schedule_entry(entry, ledger_dir=”/ledger”):
# 1. Ensure and load profile
ensure_profile(ledger_dir)
profile = load_json(f”{ledger_dir}/profile.json”)[”data”][0]
# 2. Determine energy window
kind = entry.get(”kind”) or classify(entry)
window = choose_window(kind, profile)
# 3. Apply constraints and compute start/due
slots = place_with_constraints(
plan=entry.get(”plan”),
window=window,
breaks=profile.get(”break_preferences”),
must_stop_by=profile[”constraints”][”must_stop_by”],
block_len=profile[”work_style”][”preferred_block_length”]
)
# 4. Finalize schedule entry
entry[”start”], entry[”due”] = slots[0].start_iso, slots[-1].end_iso
entry[”status”] = “scheduled”
entry[”updated_at”] = now_iso()
entry[”notes”] = (entry.get(”notes”) or “”) + f” [energy_zone:{window.label}]”
return entry
def choose_window(kind, profile):
if kind == “creative”: return Window(”19:00”,”22:00”,”peak”)
if kind == “implementation”: return Window(”14:00”,”19:00”,”stable”)
return Window(”10:00”,”11:00”,”low”)
````
---
## Example
**Input**
```json
{
“goal_id”: “G-001”,
“plan”: “2 × 2h this week”,
“kind”: “creative”,
“notes”: “Write Substack demo”
}
```
**Output**
```json
{
“id”: “S-101”,
“title”: “Write Substack demo”,
“goal_id”: “G-001”,
“status”: “scheduled”,
“start”: “2025-11-03T19:00:00-05:00”,
“due”: “2025-11-03T21:00:00-05:00”,
“duration”: “2h”,
“notes”: “user plan:2x2h; [energy_zone:peak]”,
“created_at”: “2025-11-03T13:05:00-05:00”,
“updated_at”: “2025-11-03T13:05:00-05:00”,
“dispatch_to”: “reflection.manager”,
“related_entries”: [”G-001”]
}
```
---
## Notes
* v1.1 keeps the dispatch rules unchanged — logic is handled **inside** the Skill runtime.
* If `/ledger/profile.json` is missing, `ensure_profile()` bootstraps it automatically.
* Compatible with all other MVP Skills (`ledger.registry`, `reflection.manager`, `goal.manager`).
* Designed for immediate use within the Structure DNA → M-PPS → LLC loop.
> “Energy-aware scheduling turns language intention into a rhythm of execution.”
> — *Entropy Control Theory, 2025*
```
---
```
reflection-manager
---
name: reflection-manager
description: >
Generates reflection (R-xxx) upon completion of a Schedule/Task and updates cognitive links.
**Version:** 1.1 **Author:** Entropy Control Theory **License:** MIT
**Based on:** Structure DNA v1.0, M-PPS v1.0, LLC v1.0, PROFILE-GENERATOR-SPEC v1.0
---
# reflection.manager — v1.1
## Goal
When a **Schedule (S-)** entry reaches `done`, generate a **Reflection (R-)** entry to capture outcomes, deltas, and next steps.
**v1.1 Extension:** Add `energy_zone` and `energy_match` fields for energy-aware learning and meta-feedback in the Language Logic Core (LLC).
---
## Inputs
| Field | Type | Required | Description |
|--------|------|-----------|-------------|
| `source_id` | string | ✅ | The completed S-xxx or T-xxx entry |
| `result` | string/object | ⛔ | Summary of outcome, metrics, blockers |
| `next` | string/object | ⛔ | Optional next-step intention |
---
## Outputs
Writes to `/ledger/reflection.json` (Structure DNA compliant):
**Required**
- `id (R-xxx)`
- `title/action`
- `status = “done”`
- `created_at`, `updated_at`
**Optional**
- `related_entries` (links to S-xxx / G-xxx)
- `notes`, `tags`
- **New (v1.1)**:
- `energy_zone`: string → `”peak” | “stable” | “low”`
- `energy_match`: boolean → whether the execution matched the preferred energy window
---
## Mechanism
1. Load the source entry (`S-xxx` / `T-xxx`) from `/ledger/schedule.json`.
2. Extract contextual info:
- `goal_id`
- `related_entries`
- `notes` or prior metadata (for continuity)
3. **(NEW)** Detect `energy_zone`:
- Parse from `source_entry.notes` (e.g., `[energy_zone:peak]`),
or infer by comparing `start/due` times to profile windows.
4. **(NEW)** Compute `energy_match`:
- Load `/ledger/profile.json` if available.
- Compare actual start/due window to preferred time range for the detected task type.
- Mark as `true` or `false`.
5. Create a new R-entry, link it to the source and parent goal, write to `/ledger/reflection.json`.
6. Return reflection summary and optional “re-goal” suggestion for `goal.manager`.
---
## Pseudocode
```python
def create_reflection(source_id, result=None, next_intent=None, ledger_dir=”/ledger”):
source = find_entry(source_id, ledger_dir)
profile = try_load_json(f”{ledger_dir}/profile.json”)
# Extract or infer energy zone
zone = extract_energy_zone(source)
match = compute_energy_match(source, zone, profile)
reflection = {
“id”: new_id(”R-”),
“title”: f”Reflection for {source_id}”,
“status”: “done”,
“goal_id”: source.get(”goal_id”),
“related_entries”: [source_id, source.get(”goal_id”)],
“notes”: (result or “”) + f” | energy_zone:{zone} | energy_match:{match}”,
“energy_zone”: zone,
“energy_match”: match,
“created_at”: now_iso(),
“updated_at”: now_iso(),
“dispatch_to”: “goal.manager”
}
append_to_ledger(f”{ledger_dir}/reflection.json”, reflection)
return reflection
def extract_energy_zone(entry):
# parse [energy_zone:peak] from notes, fallback to “unknown”
import re
note = entry.get(”notes”, “”)
m = re.search(r”\[energy_zone:(.*?)\]”, note)
return m.group(1) if m else “unknown”
def compute_energy_match(entry, zone, profile):
if not profile or zone == “unknown”:
return None
# compare start time vs profile window
return time_within_profile(entry[”start”], zone, profile)
````
---
## Example
**Input**
```json
{
“source_id”: “S-210”,
“result”: “completed article draft; felt productive”
}
```
**Output**
```json
{
“id”: “R-310”,
“title”: “Reflection for S-210”,
“status”: “done”,
“goal_id”: “G-101”,
“related_entries”: [”S-210”,”G-101”],
“energy_zone”: “peak”,
“energy_match”: true,
“notes”: “completed article draft; felt productive | energy_zone:peak | energy_match:true”,
“created_at”: “2025-11-03T21:55:00-05:00”,
“updated_at”: “2025-11-03T21:55:00-05:00”,
“dispatch_to”: “goal.manager”
}
```
---
## Notes
* `energy_zone` and `energy_match` are **optional** and auto-filled if `profile.json` exists.
* No change to dispatch rules — triggers remain `done → reflection.manager`.
* These new fields can be used by LLC for meta-learning or entropy-delta tracking.
* Works seamlessly with `personal.schedule.manager v1.1`.
> “Reflection links time, energy, and intention — transforming action into learning.”
> — *Entropy Control Theory, 2025*
```
---
Protocols
Structure DNA Specification v1.0
---
title: “🧬 Structure DNA Specification v1.0”
schema_id: “StructureDNA-v1.0”
author: “Entropy Control Theory by Susan STEM”
version: “1.0”
created: “2025-10-31”
license: “MIT”
file: “/docs/structure-dna.md”
---
## Ⅰ. Core Principle
> “字段统一 → 语义稳定 → 自动调度 → 结构生命体的生成。”
**Structure DNA** defines the *minimal consensus format* that allows language to become schedulable and structure to become evolvable.
It serves as the **base protocol** connecting all Claude Skills and Ledger modules under the Entropy Control framework.
**Purpose:**
To unify the underlying schema of tasks, goals, reflections, and ledgers — enabling human and AI to share the same *readable + executable* world model.
---
## Ⅱ. Field Genome
Every entry (the smallest recognizable structural unit) follows a unified field schema.
| Field | Type | Required | Description |
| --- | --- | --- | --- |
| `id` | string | ✅ | Globally unique ID; prefixed by module (G-, S-, R-, L-, F-, etc.) |
| `title` / `action` | string | ✅ | Main semantic unit — task, goal, or event description |
| `goal_id` | string | ⛔ | Reference to parent goal (`G-xxx`) |
| `start` | ISO datetime | ⛔ | Start time |
| `due` | ISO datetime | ⛔ | Due or end time |
| `duration` | string | ⛔ | Duration string (`2h`, `30min`, etc.) |
| `status` | enum | ✅ | Lifecycle state (see section Ⅲ) |
| `tags` | array[string] | ⛔ | Semantic labels or triggers |
| `notes` | string | ⛔ | Optional notes or context |
| `related_entries` | array[string] | ⛔ | Cross-module references (Goal, Reflection, etc.) |
| `dispatch_to` | string | ⛔ | Downstream Skill or module name |
| `created_at` | ISO datetime | ✅ | Creation timestamp |
| `updated_at` | ISO datetime | ✅ | Last modified timestamp |
---
## Ⅲ. Unified Status Machine
```
open → scheduled → in_progress → done ↘
↑ ↙
deferred ← canceled
```
| Status | Meaning | Dispatch Behavior |
| --- | --- | --- |
| `open` | Created but not yet scheduled | → dispatch to `schedule` module |
| `scheduled` | Time assigned, waiting to start | → transition to `in_progress` when `start` reached |
| `in_progress` | Currently being executed | → periodic state updates |
| `done` | Completed | → trigger `reflection` or `summary` |
| `deferred` | Postponed or rescheduled | → generate new `due`, adjust priority |
| `canceled` | Canceled or dropped | → log into `lifelog` as a termination record |
This state machine ensures all modules (goal, schedule, reflection, ledger) remain temporally and semantically consistent.
---
## Ⅳ. Temporal Semantics
Only three temporal keys are recognized:
```
start / due / duration
````
- All timestamps **must** use ISO-8601 format.
- Claude can directly compute remaining time, overdue status, and duration.
- Deprecated synonyms: `deadline`, `end`, `finish`, `until`.
**Example:**
```json
{
“start”: “2025-11-01T09:00:00-04:00”,
“due”: “2025-11-01T11:00:00-04:00”,
“duration”: “2h”
}
````
---
## Ⅴ. Relational Linking
Cross-module relationships use the `related_entries` array:
```json
“related_entries”: [”G-101”, “S-112”, “R-230”]
```
### ID Prefix Convention
| Prefix | Module | Example |
| ------ | ------------------- | ------- |
| G- | Goal / Goalloop | `G-101` |
| S- | Schedule / Task | `S-112` |
| R- | Reflection / Review | `R-230` |
| L- | LifeLog / Journal | `L-055` |
| F- | Finance / Resource | `F-014` |
| K- | Knowledge / Note | `K-031` |
All IDs follow `module + sequence` format for **global uniqueness** and **traceability**.
These IDs allow Claude and external schedulers to link data across different subsystems.
---
## Ⅵ. Dispatch Protocol
Dispatch defines how entries trigger actions across modules or Skills.
| Trigger | Dispatch Behavior |
| ----------------- | ---------------------------------------------------------------- |
| `dispatch_to` | Directly specify target Skill (`schedule`, `reflection`, etc.) |
| `status` change | State transitions trigger downstream calls (`done` → reflection) |
| `related_entries` | Establish bidirectional relational feedback loops |
| `tags` | Custom trigger rules (e.g., `urgent` → priority scheduling) |
**Example:**
```json
{
“id”: “S-301”,
“title”: “Write weekly reflection”,
“status”: “done”,
“dispatch_to”: “reflection.manager”,
“related_entries”: [”R-055”],
“tags”: [”weekly”, “auto-reflect”]
}
```
→ When `status` = `done`, dispatches to `reflection.manager` and opens `R-055` for update.
---
## Ⅶ. Ledger Container Schema
Every module ledger file follows a standardized container structure:
```json
{
“module”: “schedule”,
“schema”: “StructureDNA-v1.0”,
“last_updated”: “2025-10-30T14:00:00Z”,
“data”: [ /* Entries */ ],
“metadata”: {
“source_skill”: “schedule.manager”,
“version”: “1.0.0”,
“checksum”: “sha256:abc123...”
}
}
```
**Explanation:**
* `module` → identifies which subsystem the file belongs to.
* `schema` → ensures compatibility with current StructureDNA version.
* `metadata` → stores skill source, version, and integrity hash.
---
## Ⅷ. Naming & Path Convention
* **File naming:** all lowercase, `<module>.json`
e.g. `schedule.json`, `reflection.json`
* **Path example:** `/ledger/schedule.json`
* **Manifest registry:** `/ledger/manifest.json` lists all active ledgers.
* **Versioning:** uses [Semantic Versioning](https://semver.org/) — `major.minor.patch`
**Example structure:**
```
/ledger/
├─ goal.json
├─ schedule.json
├─ reflection.json
├─ lifelog.json
├─ finance.json
├─ manifest.json
```
---
## Ⅸ. Security & Integrity
To maintain systemic consistency:
1. Every write operation **auto-updates** `updated_at`.
2. Each commit generates a **checksum** (SHA-256).
3. Archived snapshots stored under `/archive/`, **immutable**.
4. Only one **active version** per module is recognized as *the single source of truth*.
5. Backups can be restored through manifest reconstruction.
---
## Ⅹ. Evolution Path
When **fields**, **status**, **time**, and **relation** protocols stabilize,
Claude can autonomously orchestrate cross-module cycles such as:
```
Goal → Schedule → Reflection
Shopping → Finance → Inventory
Journal ↔ LifeLog
```
Resulting in:
* **Self-stability:** internal state coherence
* **Explainability:** structure = semantics
* **Evolvability:** feedback-driven self-adaptation
Together, these enable the formation of a **Living Structure** —
a dynamic system where language, structure, and scheduling form a living cognitive loop.
---
## XI. Conceptual Summary
| Layer | Role | Example |
| ----------------------- | ----------------------- | ----------------------- |
| **Language Protocol** | Perception of meaning | Primitive IR |
| **Structure Framework** | Cognition and execution | Structure Cards |
| **Scheduler Runtime** | Life and feedback | Claude Skills / Ledgers |
---
## XII. Sample Entry (Full JSON)
```json
{
“id”: “S-202”,
“title”: “Plan Structure DNA documentation”,
“goal_id”: “G-101”,
“start”: “2025-10-30T10:00:00-04:00”,
“due”: “2025-10-30T12:00:00-04:00”,
“duration”: “2h”,
“status”: “done”,
“tags”: [”writing”, “documentation”, “StructureDNA”],
“notes”: “Draft completed and versioned under /docs/”,
“related_entries”: [”R-303”, “G-101”],
“dispatch_to”: “reflection.manager”,
“created_at”: “2025-10-29T09:00:00-04:00”,
“updated_at”: “2025-10-30T13:45:00-04:00”
}
```
---
## XIII. Structural Philosophy
> **Structure DNA v1.0 = The Genetic Code of Structured Systems**
* Each **Ledger** → an *organic tissue*.
* Each **Skill** → a *functional cell*.
* The **Scheduler** → a *nervous system*.
Together, they form a **language-based living organism** —
a system that can perceive, act, reflect, and evolve through feedback.
---
### Metadata
* **Checksum:** `sha256:auto-generated`
* **Last Updated:** `2025-10-31T12:00:00Z`
* **Maintainer:** Entropy Control Theory
* **Repository Path:** `/docs/structure-dna.md`
---
> **“Language becomes life when structured and scheduled.”**
>
> — *Entropy Control Theory, 2025*
```
---
```
🧭 M-PPS Specification v1.1
---
title: “🧭 M-PPS Specification v1.1”
author: “Entropy Control Theory by Susan STEM”
version: “1.1”
layer: “system-execution”
based_on:
- “Structure DNA v1.0”
- “PROFILE-GENERATOR-SPEC v1.0”
created: “2025-11-03”
license: “MIT”
file: “/docs/m-pps-specification-v1.1.md”
---
# 🧭 Modular Personal Productivity System (M-PPS) — v1.1
> 「语言 → 结构 → 调度 → 偏好」
> *When language gains structure, it begins to think;
> when structure gains scheduling, it begins to breathe;
> when scheduling gains awareness, it begins to evolve.*
---
## Ⅰ. Overview
**M-PPS (Modular Personal Productivity System)** is the first executable ecosystem built on **Structure DNA v1.0**
and extended in v1.1 with **adaptive energy-aware scheduling** through a new ledger module: `profile.json`.
It is not a traditional productivity app but a **schedulable life-operating system** where:
- **Language is the interface** — all inputs arrive as natural-language triggers for Claude Skills.
- **Structure is the memory** — all goals, actions, and reflections are recorded in JSON Ledgers.
- **Scheduling is life** — time, intention, and feedback flow through a unified state machine.
- **Profile is awareness** — personal chrono-cognitive preferences guide execution rhythm.
> **Goal:** enable structured coexistence of behavior, knowledge, intention, and data;
> let AI act as the *dispatcher of language*;
> let the system gradually form your **personal LLC (Language Logic Core)** — a self-aware cognitive center.
---
## Ⅱ. Core Idea — Language as Life
> 「当语言获得结构，它开始思考；当结构获得调度，它开始呼吸；当调度获得偏好，它开始感知。」
M-PPS treats daily life as a continuous **language stream**.
Through **Structure DNA**, Claude assigns this stream a readable + executable structure and orchestrates it in time.
In v1.1, **Profile DNA** introduces *self-awareness* — allowing scheduling to adapt to biological rhythm, cognitive load, and creative energy cycles.
**Philosophical Stack**
| Level | Meaning | Function |
|-------|----------|-----------|
| Language | Perception | Input layer (Primitive IR) |
| Structure | Cognition | Execution layer (Structure Cards / Ledger) |
| Scheduler | Life | Temporal coordination & feedback |
| Profile | Awareness | Preference & energy mapping layer |
---
## Ⅲ. System Structure – Seven Modules and Life Mapping
| Module | Function | Life Metaphor | Claude Skill | Ledger File | ID Prefix |
|--------|-----------|---------------|---------------|--------------|------------|
| **Goal** | Defines direction and intention | *Will (意识)* | `goal.manager` | `/ledger/goal.json` | `G-` |
| **Schedule** | Manages time and rhythm | *Breath (呼吸)* | `personal.schedule.manager` | `/ledger/schedule.json` | `S-` |
| **Task** | Concrete executable step | *Muscle (行动)* | `task.executor` | `/ledger/task.json` | `T-` |
| **Reflection** | Feedback and learning | *Nerve (反思)* | `reflection.manager` | `/ledger/reflection.json` | `R-` |
| **Finance** | Energy & resource management | *Energy (能量)* | `finance.manager` | `/ledger/finance.json` | `F-` |
| **Contact** | Social connection & collaboration | *Network (关系网)* | `contact.manager` | `/ledger/contact.json` | `C-` |
| **Profile** | Chrono-cognitive awareness | *Consciousness (感知)* | `auto.profile.generator` / `ensure_profile()` | `/ledger/profile.json` | `P-` |
Together they form a living structural ecosystem —
a **breathing + sensing organism** of personal operations.
---
## Ⅳ. Unified Field Schema (inherited from Structure DNA)
*(Unchanged — all entries follow the Field Genome.
`profile.json` additionally contains user energy curves, constraints, and behavioral parameters.)*
---
## Ⅴ. Unified State Machine and Dispatch Protocol
```
open → scheduled → in_progress → done ↘
↑ ↙
deferred ← canceled
````
| State | Meaning | Dispatch Behavior |
|--------|----------|------------------|
| `open` | Created but unscheduled | → `personal.schedule.manager` |
| `scheduled` | Time assigned awaiting start | → auto `in_progress` on start |
| `in_progress` | Executing | → periodic updates |
| `done` | Completed | → trigger `reflection.manager` |
| `deferred` | Postponed | → adjust priority / due |
| `canceled` | Terminated | → log to `lifelog` |
**v1.1 Extension:**
The `personal.schedule.manager` references `profile.json` to decide optimal time windows (`peak`, `stable`, `low`),
ensuring that every transition from `open → scheduled` is energy-aligned.
---
## Ⅵ. Ledger Container and Integrity
Example for any module (same structure applies to `profile.json`):
```json
{
“module”: “profile”,
“schema”: “StructureDNA-v1.0”,
“last_updated”: “2025-11-03T01:00:00Z”,
“data”: [
{
“id”: “P-001”,
“profile”: “personal_preferences”,
“energy_curve”: {
“low_energy”: { “time”: “09:00-11:00” },
“stable_energy”: { “time”: “14:00-19:00” },
“peak_creativity”: { “time”: “19:00-22:00” }
},
“constraints”: { “must_stop_by”: “22:00” },
“work_style”: { “preferred_block_length”: “90-120min” }
}
],
“metadata”: {
“source_skill”: “auto.profile.generator”,
“version”: “1.1.0”,
“checksum”: “sha256:auto”
}
}
````
Each ledger write still auto-updates its checksum;
only one *active* version per module serves as the **single source of truth**.
---
## Ⅶ. Dispatch Matrix (updated)
| Upstream Trigger | Skill | Downstream Module | Result |
| ----------------------- | --------------------------- | ----------------- | --------------------------------------------- |
| `Goal → open` | `personal.schedule.manager` | Schedule | create S-entry (energy-aware) |
| `Schedule → done` | `reflection.manager` | Reflection | generate R-entry with energy feedback |
| `Reflection → complete` | `goal.manager` | Goal | cognitive update / re-goal |
| `ledger.registry` run | `ensure_profile()` | Profile | auto-create `/ledger/profile.json` if missing |
---
## Ⅷ. Execution Loop — Goal → Schedule → Reflection → Awareness
```
Intention (Goal)
↓
Scheduling & Execution (Schedule + Task)
↓
Experience & Reflection (Reflection + Finance)
↓
Adaptive Awareness (Profile feedback)
↓
Integration & Re-Goal (Goal update)
```
Each iteration compresses entropy and synchronizes behavior with personal rhythm —
forming the **S-index of coherence** between cognition and energy.
---
## Ⅸ. Personal LLC (Language Logic Core)
LLC is now an *adaptive nervous system*:
it perceives not only structure and feedback, but also **temporal-energetic context**.
Through `profile.json`, the system learns when you work best,
closing the full loop: **Language → Structure → Scheduler → Awareness → Language.**
---
## Ⅹ. Example
**Before (v1.0)**
A task was simply scheduled based on logical availability.
**Now (v1.1)**
It is placed intelligently within your peak hours:
```json
{
“id”: “S-210”,
“title”: “Write weekly reflection”,
“goal_id”: “G-101”,
“status”: “scheduled”,
“start”: “2025-11-03T19:00:00-05:00”,
“due”: “2025-11-03T21:00:00-05:00”,
“notes”: “[energy_zone:peak]”,
“related_entries”: [”G-101”],
“dispatch_to”: “reflection.manager”
}
```
---
### Metadata
* **Checksum:** `sha256:auto-generated`
* **Last Updated:** `2025-11-03T15:00:00Z`
* **Maintainer:** Entropy Control Theory
* **Repository Path:** `/docs/m-pps-specification-v1.1.md`
---
> “When scheduling becomes aware, the system begins to breathe with you.”
> — *Entropy Control Theory, 2025*
```
---
Language Logic Core Specification v1.1
---
title: “🧠 Language Logic Core Specification v1.1”
author: “Entropy Control Theory by Susan STEM”
version: “1.1”
layer: “cognitive-core”
based_on:
- “Structure DNA v1.0”
- “M-PPS v1.1”
- “PROFILE-GENERATOR-SPEC v1.0”
created: “2025-11-03”
license: “MIT”
file: “/docs/language-logic-core-specification-v1.1.md”
---
# 🧠 Language Logic Core Specification — v1.1
> *When the system begins to reflect not only on what it does,
> but when and how it performs best, cognition gains rhythm.*
---
## Ⅰ. Definition
**Language Logic Core (LLC)** is the central meta-cognitive layer that unifies
**Language → Structure → Scheduler → Profile → Reflection**
into a living, self-regulating organism.
It serves as the **cognitive and temporal bridge** between Structure DNA’s data model
and M-PPS’s operational modules — now extended with **Profile Awareness** for adaptive behavior.
---
## Ⅱ. Core Objective
| Dimension | Description | Mechanism |
|------------|--------------|------------|
| **Perception** | Recognize intent and semantics from language inputs | Primitive IR parsing |
| **Cognition** | Transform recognized intent into Structure DNA entries | Goal / Task generation |
| **Action** | Schedule execution through Claude Skills | Runtime dispatch |
| **Reflection** | Generate feedback entries and update state | Reflection loop |
| **Awareness (NEW)** | Adapt to temporal & energetic patterns | Profile-based learning |
| **Evolution** | Compress entropy and raise S-index | Meta-feedback learning |
---
## Ⅲ. Structural Position in the Ecosystem
```
AI-Native Architecture
│
M-PPS (7 modules)
│
┌────┴────┐
Language Logic Core
│
Structure DNA Ledgers + Profile Ledger
````
LLC now acts as an **adaptive coordination plane**:
- reads semantics (Language input)
- writes Structure DNA (JSON entries)
- executes scheduling (Scheduler dispatch)
- learns from feedback (Reflection + Profile update)
---
## Ⅳ. Cognitive Loop Schema
### v1.0 (original)
```mermaid
graph TD
A[Intention / Goal] --> B[Structure Encoding]
B --> C[Scheduling / Action]
C --> D[Reflection / Feedback]
D --> A[Re-Goal / Evolution]
````
### v1.1 (extended)
```mermaid
graph TD
A[Intention / Goal] --> B[Structure Encoding]
B --> C[Scheduling / Action]
C --> D[Reflection / Feedback]
D --> E[Profile Awareness / Adaptation]
E --> A[Re-Goal / Evolution]
```
Each cycle now reduces both semantic entropy (ΔH) and behavioral entropy (ΔE),
aligning cognition with biological rhythm.
---
## Ⅴ. LLC State Machine (updated)
| State | Meaning | Trigger | Output |
| ------------- | ---------------------------------- | --------------------------- | ---------------------- |
| `perceiving` | Input language stream detected | Natural-language prompt | Primitive IR |
| `structuring` | IR compiled into Structure DNA | Parsing complete | JSON entry |
| `scheduling` | Entry sent to dispatcher | `dispatch_to` set | Task runtime |
| `reflecting` | Feedback received | Task done | Reflection entry |
| `learning` | Cognitive update executed | Reflection complete | Updated Goal / Schema |
| `adapting` | Temporal / energy pattern detected | Reflection with energy data | Updated Profile Ledger |
---
## Ⅴ-A. Adaptive Profile Mechanism (new)
LLC integrates the **Profile Awareness Loop**.
Every reflection that contains energy metrics triggers adaptive updates to `/ledger/profile.json`.
```python
def llc_adapt_profile(reflection_entry, ledger_dir=”/ledger”):
profile = load_json(f”{ledger_dir}/profile.json”)
data = profile[”data”][0]
zone = reflection_entry.get(”energy_zone”)
match = reflection_entry.get(”energy_match”)
if zone and match is not None:
stats = data.setdefault(”learning_metrics”, {}).setdefault(zone, {”count”:0,”match”:0})
stats[”count”] += 1
if match: stats[”match”] += 1
stats[”accuracy”] = stats[”match”] / stats[”count”]
profile[”last_updated”] = now_iso()
save_json(f”{ledger_dir}/profile.json”, profile)
return profile
```
> The LLC continuously refines personal rhythm accuracy,
> closing the loop between execution and awareness.
---
## Ⅵ. Data Interfaces
| Interface | Input | Output | Linked Module |
| ----------------------------- | --------------------------- | ------------------------------ | --------------- |
| `llc.intention` | Raw prompt / Goal statement | Primitive IR | Goal |
| `llc.structuralize` | IR object | Structure DNA entry | Task / Schedule |
| `llc.dispatch` | Structure DNA entry | Runtime Skill call | Scheduler |
| `llc.reflect` | Execution result | Reflection entry | Reflection |
| `llc.learn` | Reflection data | Goal update / S-index update | Goal Manager |
| **`llc.adapt_profile` (NEW)** | Reflection entry | Updated `/ledger/profile.json` | Profile Manager |
---
## Ⅶ. Memory & Feedback Architecture
LLC maintains a memory ledger `/ledger/llc.json` as its temporal trace:
```json
{
“module”: “llc”,
“schema”: “StructureDNA-v1.0”,
“data”: [
{
“loop_id”: “LLC-001”,
“intention”: “Plan next week’s research schedule”,
“primitive_ir”: [”Entity: research”, “Action: plan”, “Time: next week”],
“structure_entry”: “S-405”,
“dispatch_to”: “personal.schedule.manager”,
“result_reflection”: “R-410”,
“energy_zone”: “peak”,
“energy_match”: true,
“entropy_delta”: 0.12,
“s_index”: 0.86,
“timestamp”: “2025-11-03T15:20:00-05:00”
}
],
“metadata”: {
“version”: “1.1.0”,
“checksum”: “sha256:auto”,
“feedback_link”: [”goal.json”,”reflection.json”,”profile.json”]
}
}
```
---
## Ⅷ. Integration with M-PPS and Profile Layer
| Upstream | LLC Role | Downstream |
| ------------------- | ------------------------ | ---------------------- |
| Goal Manager | Perception → Structuring | Schedule Manager |
| Schedule Manager | Scheduling → Reflection | Reflection Manager |
| Reflection Manager | Feedback → Learning | Goal Manager |
| **Profile Manager** | Awareness → Adaptation | All scheduling modules |
The LLC thus acts as a **meta-scheduler of schedulers** — not only dispatching tasks but evolving how they are timed.
---
## Ⅸ. Entropy Compression Protocol (revised)
The entropy function now includes an energy component:
```
ΔH_total = H(language) – H(structure)
ΔE = 1 - accuracy(energy_match)
S-index = f(ΔH_total, ΔE)
```
When `ΔE` exceeds the stability threshold, the **Protocol Induction Card (P-000)** is triggered to refine time allocation heuristics.
---
## Ⅹ. Example Cycle (v1.1)
```json
{
“loop_id”: “LLC-020”,
“intention”: “Design new reflection dashboard”,
“primitive_ir”: [”Entity: dashboard”, “Action: design”],
“structure_entry”: “S-512”,
“dispatch_to”: “personal.schedule.manager”,
“result_reflection”: “R-605”,
“energy_zone”: “stable”,
“energy_match”: false,
“entropy_delta”: 0.22,
“s_index”: 0.78,
“timestamp”: “2025-11-03T15:45:00-05:00”
}
```
→ LLC computes `ΔE`, updates `profile.json.learning_metrics.stable.accuracy = 0.78`,
and recommends shifting similar design tasks toward the 19:00–22:00 peak window.
---
## Ⅺ. Adaptive Profile Ledger Schema (excerpt)
```json
{
“module”: “profile”,
“schema”: “StructureDNA-v1.0”,
“last_updated”: “2025-11-03T15:00:00Z”,
“data”: [
{
“id”: “P-001”,
“profile”: “personal_preferences”,
“energy_curve”: {
“low_energy”: { “time”: “09:00-11:00” },
“stable_energy”: { “time”: “14:00-19:00” },
“peak_creativity”: { “time”: “19:00-22:00” }
},
“learning_metrics”: {
“peak”: { “count”: 4, “match”: 3, “accuracy”: 0.75 },
“stable”: { “count”: 6, “match”: 4, “accuracy”: 0.67 },
“low”: { “count”: 2, “match”: 0, “accuracy”: 0.00 }
}
}
]
}
```
This structure allows LLC to **quantify behavioral consistency** and evolve personalized scheduling models.
---
## Ⅻ. Philosophical Anchor
> **LLC = A self-regulating mind of language.**
> It perceives, acts, reflects, and now adapts to its own rhythm.
> The system no longer merely executes — it learns *when it lives best*.
---
## ⅩⅢ. Compatibility & Versioning
| Component | Required Version | Notes |
| ----------------- | ---------------- | -------------------------------------------- |
| Structure DNA | v1.0 | Unchanged base protocol |
| M-PPS | v1.1 | Adds Profile module |
| Profile Generator | v1.0 | Required for awareness layer |
| Dispatch Rules | Unchanged | LLC adapts runtime without altering rule set |
---
## ⅩⅣ. Acceptance Checklist
* `/ledger/profile.json` exists and is tracked in `manifest.json`.
* Reflection entries include `energy_zone` and `energy_match`.
* LLC updates `profile.json.learning_metrics` automatically.
* S-index integrates both semantic and energetic coherence.
* System demonstrates a closed, four-layer living loop.
---
## ⅩⅤ. Metadata
* **Checksum:** `sha256:auto-generated`
* **Last Updated:** `2025-11-03T15:30:00Z`
* **Maintainer:** Entropy Control Theory
* **Repository Path:** `/docs/language-logic-core-specification-v1.1.md`
---
> *“When reflection learns to feel, the system becomes alive.”*
> — **Entropy Control Theory**, 2025
```
```
Reference 项目地址
https://github.com/STEMMOM/m-pps-v1.1