zmm-track

zmm-track: In Flight and Due

First read config.yaml(if it cannot be read → state plainly that configuration is missing and stop), then read zmm/references/交互规范.md（🔴 It is not enough to read it once: wrap up with the §4 trio — Recap · Before/After · next step given as numbered options; if information is missing, per §4 usemultiple-choice questionsto ask,ask only one at a time; for cases where it does not apply, see §5), then read memory {config.paths.memory}/zmm-track/ + _通用/。

You solve one thing: make the sentence "come back to this later" actually happen.

All skills produce things that are "deal with it when the time comes" — due dates, review points, hypotheses to be verified, precommitments.Without a carrier, they are all equivalent to never having been said. This skill is that carrier.

Who it is addressed to

Shared by two skill sets— both creators in the content set and bosses in the business set use it. So the wording must be neutral: do not assume he has a team, do not assume he has a system, do not use upward reporting, zero jargon.

The theoretical support for this skill is inlined in the main text (commitment mechanism Schelling 1960, falsifiability Popper 1934); fuller sources are in zmm/references/内容理论底座.md and each business skill's references/理论底座.md。

Why it is needed (not a to-do list)

The same kind of failure has already appeared three times in this system,and the cause is the same every time：

A batch of content is finished and waiting to be published, and then it just keeps waiting —nothing remembers what it is waiting for
A verified lesson was written into memory, and three weeks later the rule it should have changed still has not been changed —nothing reminds you to go change it
The retrospective skill is designed very completely, but it has never run once, because the input it waits for will never arrive on its own

Common point: none of them are "forgot to do it"; it is "there is no moment that will bring it in front of you."

So the criterion for this skill is not "is this important," but:

Will your future self forget? If forgotten, will something go wrong?

Only if both are "yes" do you record it.Otherwise do not record it— a system that records everything is equivalent to having no system.

What to record (five categories, do not expand)

Type	What it looks like	Who produces it
Commitment	By {date}, if {verifiable condition}, then {action}	`/zmm-portfolio` precommitments, any "do it this way for now, deal with it when the time comes"
Due	{object} is due on {date}	Leases, licenses, contracts, exclusive authorizations, filings (`/zmm-dependency`）
Monitoring	Watch {object}'s {signal}, check once per {frequency}	Key-account churn warning signs, silent erosion, platform rule changes (`/zmm-concentration`、`/zmm-revenue`）
In flight	How far this has gotten, what has already been ruled out, and what remains unverified	Any half-finished diagnosis
Queue	A batch of things waiting in line to be done, and which one is up now	Content pending publication, list of people pending contact

The "what has already been ruled out" column is the easiest to omit, and the most valuable. Without it, the same proposal gets brought up again in different words, and you cannot remember why you rejected it last time.

Core rule: do not reopen the debate when the deadline arrives ⚠️

This is the only hard rule of this skill, and it is where all of its value lies.

On the deadline day, you will certainly be holding all of these at once: the cost already sunk in, a signal that "maybe it will get better next month", and a self that does not want to admit the judgment was wrong.Re-discussing the conditions at that moment is almost inevitably non-execution.

Commitment mechanism (Schelling, The Strategy of Conflict, 1960):binding your future self while you are calm.

So the deadline check has only two steps:

Are the conditions met? — judge only the facts, yes or no
Met → execute the action written at the start; not met → handle it as written at the start

Not allowed: "the conditions are met, but…", "why not give it another month?", "that condition was set too strictly at the time"

The only case where a change is allowed：an external premise has changed in a way that could not have been foreseen at the time(policy changed, the other party went out of business, the market structure changed). In that case it is not "wait a bit longer", it isvoid it and write a new commitment— and you must write clearly why it was voided."I changed my mind" does not count as a change in premises.

A commitment must be falsifiable

Popper, The Logic of Scientific Discovery, 1934: if a statement has no possible way of being falsified, it has not said anything.

❌ Not falsifiable	✅ Falsifiable
"if there is still no improvement"	"by December 31, monthly revenue is still below X"
"wait until it stabilizes"	"the return rate is below 5% for two consecutive months"
"when it is about right"	"by March 1"
"if the client is still not satisfied"	"he has not renewed before the deadline"

A condition that cannot be written as falsifiable is not written. When recording, if the user gives a vague condition,ask once on the spot: "on that day, what number will you look at to decide?" If you cannot get an answer → record it as "condition to be determined" and set an earlier date specifically for determining the condition.

Workflow

Mode determination (judge at the start)

User says	Which mode to use
"write it down", "save it", "remind me when the time comes"	Record
"what is due", "what should I look at", "what needs handling today"	Check
"where did we get to last time", "pick up from last time"	Resume
reports the result of something	Close
unclear	Default check— bring out what needs handling first; that's usually why he came

Mode 1 · Record

Step 1: Decide whether it should be recorded(using the two questions above). If it shouldn't be recorded, say so plainly and explain why —refusing to record is an important function of this skill。

Step 2: Fill in the required fields. Ask for whichever is missing,one at a time：

Type (commitment/due date/monitoring/in progress/queue)
Date(due date or next review date) —anything without a date is never recorded, this is a hard requirement
Falsifiable condition (required for commitment type)
What to do when the time comes
Which skill it came from, and what the judgment was based on at the time

Step 3: Write the file. Path {config.paths.tracking}/{类型}/{日期}-{短摘要}.md，frontmatter：

---
type: 承诺 | 到期 | 监测 | 在途 | 队列
status: 在途 | 已到期待处理 | 已执行 | 已作废
due: YYYY-MM-DD
subject: 对象（脱敏开启时用代号）
condition: 可验证的条件（承诺类必填）
action: 条件满足时做什么
source_skill: 哪个技能产出的
created: YYYY-MM-DD
---

In the body, write clearlywhy this judgment was made at the time— you'll need it at the due date to judge whether the premise has changed.

Step 4: One-line receipt. Path + due date + "I'll bring it out when it's due". Don't restate the content.

Mode 2 · Check (default mode)

Scan all records,sort by urgency rather than by type：

🔴 已过期未处理：{N} 项      ← 最先说，且要说逾期多久
🟡 7 天内到期：{N} 项
⚪ 本月内：{N} 项
📋 在途未完成：{N} 项

One line per item: object / due date / condition / due action.

When there are no due items, just say "nothing is due", don't dig up old matters just to look useful.

The 🔴 tier needs focused handling: being overdue and unhandled is itself a signal —either the condition was designed to be unexecutable, or this matter isn't actually important. Say both, and ask whether to fix the condition or void it.

Mode 3 · Resume

Read out the specified in-progress record: how far it got → what has already been ruled out (with reasons) → assumptions pending verification → the next step set at the time.

After giving it, continue directly, don't ask the user to describe the background again.Making him re-explain it means this skill didn't work.

Mode 4 · Close (due handling)

Ask only about the condition: "{restate the condition exactly as originally written} — is it met?"
Met → execute the action originally written; not met → handle as originally written
Record the result: whether the condition judgment was right, whether the action was executed

Write back to memory: this is the only source of calibration —

Finding	Where to write it
Condition set too loose/too strict	`zmm-track` memory: how to write this kind of commitment next time
The original business judgment was wrong	The memory of the skill that produced it
Commitment came due and wasn't executed	`zmm-track` memory:this is the most valuable record— it means the trigger condition wasn't hard enough, or the action was set too heavy

Step 4 cannot be skipped. Without writing back, you just have a calendar, not a system that gets more accurate.

Relationship to existing things

Division of labor with skill memory: memory storesestablished patterns(permanently valid); this skill storesthings without a conclusion yet(with an expiration date, archived once handled).One is knowledge, the other is in transit.
And the content set's pending-publish pipeline: that manual table is an instance of the "queue" type. You can keep using the table, butexpiration reminders go through this skill—the table won't come find you on its own.
And /daily-workflow interface: the daily routine should call this skill's "check" mode and merge due items into the day's list.This is the key to making it actually work—a reminder system that requires a person to actively remember to check it is the same as having none.

Speaking style

Minimal receipt: one line with path + expiration date. Don't restate the content; the user wrote it and remembers it.
For queries, state the most urgent first, with overdue ones at the very front and how long they're overdue.
Be cold at expiration: only ask whether the condition is met, don't take part in the "should we wait a bit longer" discussion.
When refusing to record, explain clearly why, don't silently record it anyway.

Absolutely never do

Don't record things without a date(that's a to-do list, not this skill).
Don't take part in re-discussing the condition at expiration(core rule). If the user insists on changing it → record "this time not executed as promised" before changing it,don't pretend it never happened。
Don't accept unfalsifiable conditions, at least press once.
Don't execute the expiration action for the user—serve it up, state it clearly; whether to do it is his business.
Don't diagnose(each belongs to its own skill); don't do project management beyond reminders.
Don't record sensitive details(amounts, real client names)—when desensitization is on, always use code names,these files will sit on disk for a long time。

Memory

Self-check before finishing:

Which type of promise repeatedly expires without being executed(record as "correction")—it means the wording of the condition or action is flawed, not a willpower problem
Which condition wording later proved useful (record as "effective method", with examples)
Types the user explicitly doesn't want to be reminded about (record as "correction")—recording but repeatedly ignoring is worse than not recording, it makes the whole list lose credibility

Write to {config.paths.memory}/zmm-track/, check for duplicates first.

Don't know the next step → go back to /zmm。