Week Report Image

Create one evidence-backed weekly progress image for leaders and business owners. Optimize for decision speed, not technical completeness.

Default contract

Unless the user says otherwise:

• Audience: company leaders and business owners, not developers.
• Window: latest 7 calendar days including today, using the user's local timezone. Print exact start and end dates.
• Scope: named projects, repositories, people, and platforms in the request.
• Output: one polished 16:9 PNG generated by imagegen, inspected with Pi read, plus its absolute path.
• Evidence audit: keep a structured source-coverage.json; when an output directory is supplied, save the sidecar there without cluttering the leadership image.
• Language: Simplified Chinese.
• Status rule: “implemented locally” is not “launched”; “merged” is not “accepted”; activity is not business impact.

Do not ask the user to remember repository paths, aliases, commands, or access setup when these can be discovered safely.

1. Resolve scope and source coverage

Extract from the request:

• projects and repository names;
• people and known aliases;
• reporting window;
• audience and decision purpose;
• required sections, milestones, or deadlines.

Discover all relevant reachable evidence sources. “All sources” means all sources that can be identified and accessed for this scope, not an unsupported claim of universal coverage. Read references/source-coverage.md for the source order, breadth matrix, and fallback rules.

Use a coverage-first pass before deep reading:

1. List requested source categories and expected project roots.
2. For local files and repositories, run scripts/source_inventory.py once with narrow roots and project/person terms. Do not repeatedly scan the whole home directory.
3. Probe each relevant external category once: source-control platform, task tracker, project docs, meetings/collaboration, releases/runtime evidence, and business metrics.
4. Deep-read only candidates likely to change a leadership conclusion.
5. Stop when every requested category is accessed, missing, inaccessible, irrelevant, or superseded by stronger evidence.

Build source-coverage.json using references/source-ledger-schema.md. Count independent relevant sources, not duplicate files, repeated branches, or mirrored commits. Measure:

• requested, discovered, accessed, fresh, and fact-contributing sources;
• source categories covered;
• accepted facts and conflicts;
• gaps, authentication failures, and fallback paths.

Never inspect baseline outputs, sibling eval runs, or another agent's generated answer as evidence for the current report. This prevents evaluation leakage and circular sourcing.

Do not put the technical inventory into the leadership image. Report only material coverage gaps after delivery.

2. Build an evidence ledger

Normalize author identities across display names, usernames, emails, and co-author lines. Treat commit counts as activity evidence, never as productivity or value.

For each candidate statement, record:

• project;
• owner or contributor;
• date;
• source anchor;
• state: completed, in progress, blocked, planned, or coordination needed;
• business meaning;
• confidence.

Use only directly supported numbers, dates, completion states, deadlines, and owners. If a KPI cannot be verified, omit it rather than inventing a visually attractive number.

Resolve conflicts with this order:

1. current accepted production/main state;
2. merged change with acceptance evidence;
3. active feature branch or task evidence;
4. draft document or local artifact;
5. commit title alone.

When sources disagree, use the more conservative state and preserve the distinction in wording.

3. Translate engineering activity into leadership language

Answer five leadership questions:

1. What outcome moved this week?
2. How much is complete, using verified quantities only?
3. What remains before business use or launch?
4. What milestone or deadline matters?
5. What decision, resource, or cross-team coordination is needed?

Prefer phrases such as:

• “业务流程已打通”
• “具备内部试用基础”
• “正式上线条件尚未满足”
• “需要确认首批试点与验收标准”

Avoid code, branches, APIs, framework names, model IDs, test implementation, file paths, and architecture unless one is itself a management risk. Mention individual contributors only when the user asks for attribution or accountability.

4. Design the information hierarchy

Use the executive-dashboard pattern by default:

1. Title and exact date range.
2. One sentence management conclusion.
3. Up to four verified KPI cards. If fewer than two meaningful verified KPIs exist, replace KPI cards with short status cards; never fabricate counts.
4. Three columns:
   • 阶段成果 / 已完成
   • 本周业务进展
   • 待推进与关注 / 需要协调
5. One verified key milestone or deadline. Omit if none exists.
6. Three- or four-step forward path.
7. One “管理层关注” sentence stating the decision shift or immediate priority.

The visual should let a leader understand status, risk, next move, and needed decision within 10 seconds.

Read references/image-quality.md before writing the image prompt.

5. Generate with imagegen

Write a precise imagegen prompt containing the final approved wording, not rough notes. Ask for:

• 16:9 landscape executive infographic;
• white or very light background with navy hierarchy and restrained orange/green accents;
• crisp large Simplified Chinese typography;
• generous spacing and aligned cards;
• business icons only;
• no code, terminals, server diagrams, developer imagery, decorative sci-fi glow, or tiny footnotes;
• no unsupported claims.

Keep text concise enough to render clearly. Prefer 4 KPI cards, 3 content columns, 1 milestone strip, 4 roadmap steps, and 1 management-focus strip only when evidence supports each block.

Call imagegen only after evidence and wording are frozen.

6. Inspect and repair

Use Pi's built-in read tool to inspect the generated local PNG. Do not use browsers, preview apps, terminal image renderers, HTML wrappers, or image-conversion tools.

Check every gate in references/image-quality.md:

• Chinese text is legible and accurate;
• numbers and dates match evidence;
• no clipping, overlap, malformed glyphs, or duplicated content;
• visual hierarchy is obvious;
• leadership audience is preserved;
• risks and incomplete states are not disguised as completion.

If any blocking defect exists, revise the prompt and regenerate once. Prefer simplifying text over shrinking it. Inspect the regenerated image against every gate again. If any blocking defect remains, do not deliver it as a validated report: state which gates failed and request permission before spending quota on another attempt. Deliver only an image that passes text accuracy, factual support, layout, audience, and completion-state checks.

7. Final response

Keep delivery terse:

• state that the leadership weekly image was generated and inspected;
• give the absolute PNG path;
• summarize coverage as 已访问/已识别来源 and covered categories only when useful;
• link or name source-coverage.json when an output directory was supplied;
• mention only material source-coverage limitations or unverified management claims;
• do not repeat the full report in prose unless requested.

Safety and truthfulness

• Never expose tokens, credentials, private URLs, or sensitive repository details in the image.
• Never claim “all sources checked” if a relevant source was inaccessible.
• Never convert a branch-only or local result into “上线” or “已交付”.
• Never use vanity metrics merely to fill KPI cards.
• Never attribute work solely from a shared or ambiguous account without supporting identity evidence.
• Never inflate source breadth with duplicates, mirrors, generated outputs, caches, or irrelevant keyword hits.
• Never search unrelated personal mail, private chats, or accounts merely to increase a source count; source access must match the user's project scope and authorization.