reflect-on-vibe-code-growth

Looking in the Mirror · Vibe Code Growth Journey

Shared communication

Apply TW plain-language and guidance rules to user-facing work. Explain terms in context; preserve the user's chosen 新人/入门/熟练/老手 level without inferred changes. 新人 and 入门 receive detailed explanations; every level receives needed and bug explanations unless the user explicitly waives that scope. Soul and prose modes never disable this baseline. Load the shared reference for task entry, level management, or explanation decisions.

Organize the currently available evidence into a new complete capability assessment, and when the user explicitly requests saving, append it as an immutable local resume node. The previous resume is only a piece of historical evidence, not the scoring anchor for this round, not a capability ceiling, not a fixed denominator, and not a permanent scale.

Restore evidence boundaries

First read the project authorities, Git/working tree, deliverables, verification receipts, and user-authorized Codex/Chat records accessible to the current task. Record the actual observation window and gaps for each source; do not fabricate inaccessible time periods.

By default, save only desensitized summaries, metrics, evidence references, and judgments; do not save complete raw chats, private logs, credentials, keys, cookies, session materials, or non-desensitized content. If the user only requests analysis, do not create a local resume without authorization.

Clearly mark each piece of evidence as one of the following:

exact: directly obtained from reproducible derivations, files, hashes, or machine records;
user-reported: self-reported by the user, retaining the original definition;
phase-estimate: stage estimate, with assumptions and error margins stated;
behavioral-evidence-score: a score based on behavioral evidence, not pretending to be a precise measurement;
unverifiable: cannot be verified with current evidence.

When Chat has no unified precise Token export, do not convert visible characters into Tokens, and do not directly add Chat and Codex Tokens together. Only when there is a named official export with consistent definitions may it be marked as exact。

Reassess the complete capability network

Each re-verification reassesses from current evidence, not by "continuing the calculation" upward or downward from old scores. At minimum review:

decisiveness;
error correction ability and response speed;
learning speed and cross-domain transfer;
driving synchronization rate and continuous calibration;
product definition and architecture;
acceptance evidence and delivery;
Token economy;
project portfolio and sustainability;
deep thinking ability: problem layering, causal chains, counterexamples, and viewpoint revision in social issues, future outlooks, real-world observation feedback, project structure, planning, and technical discussions;
upstream architecture ability: self-developed architecture, understanding and applying external architecture, abstracting stable constraints, deciding downstream interfaces, and turning architecture into authority or workflows;
innovation ability: transforming existing projects, reusing wheels, optimizing and upgrading, cross-domain combination, and forming new structures or new experiences after absorbing reference materials.

Do not double-count: deep thinking evaluates the discussion process and real-world feedback, and is not equivalent to learning speed; upstream architecture evaluates whether one can define and constrain downstream, and is not equivalent to general system understanding; innovation evaluates the absorption and transformation of materials and verifiable modification, and is not replaced by novel naming, the number of reference files, or the number of opened pits.

Allow the discovery of new dimensions and the merging or retirement of old dimensions. For each current dimension, save a stable dimensionId、confidence、scoringMethod, evidence references, and the current score or reason it cannot be scored. The score is a behavioral evidence judgment for the current window, not a future capability ceiling.

Report project completion separately: definition, implementation, automated verification, build/packaging, manual acceptance, release/online readback. No preceding gate may be passed off as a subsequent gate.

Execute the re-verification protocol

Before reading the previous node, first run the history validation:

node scripts/validate-mirror-record.mjs --root <照镜子履历根目录>

If hashes do not match, the index has drifted, predecessors are missing, there are orphan nodes, or the scale mapping is incomplete, stop the continuity conclusion and report corruption; do not quietly start from zero.

When comparing, follow:

Old nodes retain the scores, scales, and evidence windows from that time, and history is not rewritten.
First re-evaluate the current complete network, then look at the differences.
Review whether the old evidence is still valid and whether re-verification is needed, but do not let historical high scores lock down the current judgment.
rubricVersion When changed, a dimension mapping must be provided.
Only compute numerical values for dimensions whose scale, meaning, and scoring method are comparable delta。
Items that are merged, retired, or have a scale change are marked "scale changed, not directly comparable" and must not be forcibly calculated.
The report simultaneously presents the historical trajectory, the current re-evaluation, and comparable changes.

The structured history follows mirror-record.schema.json。

Generate the report and save the history

By default, perform dual-track output:

First, in the reply body, provide a complete Markdown text assessment form that can be read, copied, and saved independently;
Then use vibe-code-growth-report.html to generate a seven-chapter interactive report: condensed summary table, capability network, four core items, Token economy, project achievement, journey, conclusion.

The interactive report follows the visual grammar of the original "Vibe Code Two-Month Capability Cockpit" canvas: compact titles and scope legend, lightweight section buttons, quiet tables, a hierarchical network of core-capability cluster-dimension, selected node details, horizontal allocation bars, project completion table, timeline, and two-column conclusion. Do not apply the TavernWeave beginner tutorial, sidebar course, chapter reader, or promotional landing page shell. All core, capability cluster, and dimension nodes must be native buttons with full hit areas, supporting mouse and keyboard selection; do not disguise an SVG group where only a circular local area is hittable as a fully clickable node.

The two outputs must come from the same structured record, and the evidence boundaries, scores, project gates, and conclusions must not drift from one another. Do not provide only a set of short cards or an HTML path to replace the complete textual judgment.

When the user says "only a text assessment" or "output a single text assessment form," run render-text-assessment.mjs or directly output a continuous Markdown in the same format; do not force the generation of a canvas, and do not split the text into multiple attachments. When the user only wants the canvas, the main long text table may be omitted, but the canvas must still retain an entry point for viewing, copying, and exporting the complete text assessment.

The text assessment must include at least: conclusion first, evidence boundaries, complete capability network, four core items, Token economy, the six project gates, growth journey, historically comparable changes, next-stage recommendations, and final judgment. Each major capability must present "current judgment-evidence-limitations-next step" and must not be compressed into only a score and a one-sentence label.

The interactive template must be driven by the current record data, and must not write any user's specific Tokens, scores, projects, or first-report numbers as default values. The information density of the canvas should align with the text assessment: after the condensed summary table, it must still retain the complete dimension table, evidence expansion, six-gate project status, historical mapping, and action protocol, and must not use decorative large cards to swallow the substantive content.

In the report, "Export HTML," "Export JSON," and "Export text assessment" only produce portable copies. Authoritative local saving must be done by the script:

node scripts/save-mirror-record.mjs \
  --root <照镜子履历根目录> \
  --record <当前评估草稿.json> \
  --template assets/vibe-code-growth-report.html

The script verifies the existing chain, deterministically generates a single assessment.md, computes the record/report/assessment SHA-256, creates a new records/<recordId>/record.json、report.html and assessment.md, then atomically updates index.json and latest.json. It refuses to overwrite existing nodes, refuses sensitive fields, refuses broken chains, and verifies the mapping when the scale changes. Legacy nodes without assessment.md are still verified read-only according to the original hash rules, and must not be backfilled.

After saving, run the validation script again and return the absolute path, the record/report/assessment hashes, and the predecessor relationship. Do not add the .private history, the full conversation, or the user's specific ability numbers to the public Skill source code.

Delivery

Return:

the current evidence window, source categories, and unverifiable gaps;
the complete ability network and the four core judgments;
tiered project attainment, Token economics, and sustainability;
historical trajectory, current reassessment, comparable changes, and scale-change items;
the single text assessment, interactive report, and structured record paths;
automatic verification, and the unexecuted real host/new task discovery/installation/manual acceptance/commit/release gates;
the next explicit acceptance or re-verification instruction.