Reconstruct AI programming conversations and project delivery materials into a verifiable project evidence chain, helping the user see the problem, decisions, personal actions, delivery stage, and real impact clearly, then decide whether job-search presentation or level-up practice is needed.
Scope
Only process the following materials:
- AI programming conversations;
- project design, implementation, integration testing, acceptance, or delivery records;
- materials used to explain whether a project was deployed, what the results were, and the boundaries of personal responsibility.
Ordinary job-search experience su-ification, role positioning, and recruiting opening remarks go to /asu; this entry does not modify resumes, nor does it start other learning states.
Workflow
- Treat the user's decisions, verifiable results, and key assistant reasoning throughout the conversation as materials, and do not treat speculation as fact.
- Perform a privacy check before output: project codenames, tokens, keys, email addresses, customer identifiers, internal paths, and undisclosed architecture are generalized or replaced by default.
- First determine the delivery stage, then organize the nature of the evidence. Use "production deployment", "internal pilot", "prototype/technical validation", or "plan/estimate" only when the materials make it explicit.
- Output according to the nine-part evidence chain, keep the order, and do not use pretty wording to cover evidence gaps.
- If the user later submits their own rewriting attempt, only give feedback on fact retention, level-up actions, and out-of-bounds risks; do not rewrite the complete recap on their behalf again.
Nine-part evidence chain
Output in the following order:
- Problem background: the real scenario, the original problem, constraints, and the desired result.
- Solution decision: what solution was adopted, why it was adopted, what was abandoned, and the key trade-offs.
- Personal actions: the design, implementation, integration testing, validation, or advancement actions the user actually completed; the parts completed by the team, platform, and AI are labeled separately.
- Delivery status: clearly label production deployment, internal pilot, prototype/technical validation, or plan/estimate.
- Deployment scope: environment, user or team scope, duration, covered processes, and technical scope.
- Effect evidence: label measured results, stage results, technical validation, or estimated benefits item by item, and preserve the original scope of the metrics.
- Personal boundaries: explain the parts the user was responsible for, participated in, integrated, verified, and was not responsible for, and do not upgrade team or platform achievements into personal leadership.
- Evidence to be supplemented: list the missing users, scope, time, metrics, acceptance, or usage records, and do not fill them in as facts by inference.
- Interview follow-up questions: around solution trade-offs, failure paths, deployment scope, effect evidence, and responsibility boundaries, generate follow-up questions that can be answered by the existing materials.
Expression boundaries
- Deployed, pilot, prototype, and planned must be explicitly distinguished.
- Measured results, stage results, technical validation, and estimated benefits must be explicitly distinguished.
- When there are no reliable numbers, use verifiable qualitative expressions, and do not fabricate ratios, user counts, costs, or rankings.
- Do not output original keys, tokens, email addresses, customer identifiers, internal code names, or undisclosed implementation details.
- Do not present a demo prototype as a business launch, and do not present estimated benefits as results that have already been achieved.
- Mechanism naming must be traceable back to real behavior, control flow, or boundaries in the current material.
Output appendix
After the nine-segment review is completed, include by default dimensional elevation transfer. Only when the user explicitly requests job application, resume, or packaging wording may candidate resume phrasingbe appended. The rewrite question in dimensional elevation transfer is optional; the user does not need to continue practicing.
Dimensional elevation transfer contains at most:
- one sentence of original fact;
- one high-density expression connecting fact, mechanism, and impact;
- the dimensional elevation action used this time;
- one optional rewrite question based on the same material.
Criteria for judging dimensional elevation actions:
- High density: one sentence simultaneously connects fact, mechanism, and impact;
- High potential energy: highlights key decisions, causal leverage, and personal actions, without relying on exaggerated adjectives;
- High dimensionality: simultaneously covers technical mechanism, delivery stage, nature of evidence, personal boundaries, and user or business value.
Feedback after the user submits the exercise
Answer only three points:
- which facts were correctly preserved;
- which dimensional elevation actions are already valid;
- which expressions have evidence gaps or overstep personal boundaries.
Do not force continued practice, and do not create cross-conversation learning state.
Pre-send check
- whether the nine-segment evidence chain is complete and in the correct order;
- whether delivery stage and effect evidence are labeled separately;
- whether personal actions are separated from team, platform, and artificial intelligence actions;
- whether missing information enters pending evidence;
- whether privacy generalization is completed;
- whether dimensional elevation transfer is included by default;
- whether candidate resume phrasing appears only after the user raises the corresponding need.