The seeded forecast module opens on six rows of zeros: commit / best-case / pipeline are 0 in 6 of 7 snapshots, so 4 of its 13 columns are dead on a fresh install

[os-zhuang]

The seeded forecast module opens on six rows of zeros: commit_amount / best_case_amount / pipeline_amount are 0 in 6 of 7 snapshots, so 4 of its 13 columns are dead on a fresh install

What a sales manager sees

销售预测 / Forecasts, grouped by period, on a fresh pnpm demo:reset:

周期	配额	已成交金额	承诺金额	最佳情况	管道金额	预期金额	达成率	覆盖倍数
Q4 2025	1,200,000	1,308,000	0	0	0	1308000	109	0
Q3 2025	1,100,000	1,045,000	0	0	0	1045000	95	0
Q2 2026	1,400,000	1,485,000	0	0	0	1485000	106.07…	0
Q1 2026	1,300,000	1,196,000	0	0	0	1196000	92	0
Jun 2026	460,000	414,000	0	0	0	414000	90	0
Jul 2026	480,000	505,000	0	0	0	505000	105.20…	0

Measured: GET /api/v1/data/crm_forecast?top=20 → 7 rows, and commit_amount, best_case_amount, pipeline_amount, coverage_ratio are each 0/null in 6 of the 7.

A forecast whose commit, best-case and pipeline are all zero cannot answer the question the object exists for — will we make the number? Closed-vs-quota alone is a scoreboard, not a forecast. coverage_ratio is 0 for the same reason: its numerator is pipeline_amount.

Where it comes from

src/data/revenue.seed.ts zeroes them explicitly for the historical rows:

// :342-344, and again at :396-398
pipeline_amount: 0,
best_case_amount: 0,
commit_amount: 0,

One row (:381-383) carries real numbers — 760000 / 540000 / 360000 — and it is the only one where the module looks like a forecast. So the shape is already authored; it is just not applied to the rest of the set.

forecast-snapshot.flow.ts computes all three correctly from open opportunities (its header documents the rules: pipeline = every open opp closing in the period, best case = open with forecast_category ∈ {best_case, commit}, and so on). But on a fresh install the scheduled sweep has not run, so the seed is what a first-time user sees.

This is the same shape as #1212 (the quota-attainment dashboard widget that is empty on a fresh install) — the demo dataset not exercising a capability the app actually has.

Suggested

Backfill the three columns in revenue.seed.ts for the historical periods, consistent with each period's closed amount and quota — the arithmetic does not have to be real, it has to be plausible and non-zero so the columns demonstrate what they are for. coverage_ratio then computes itself.

Worth checking at the same time whether the seeded periods should include the current quarter: every row above is historical, so the one forecast a manager would actually open — this quarter's — does not exist until the scheduled flow writes it.

Adjacent, filed upstream

The same list shows 达成率 as 106.07142857142857 and 预期金额 as 1485000 (unseparated) — both are Field.formula({ scale: 2 }) fields, and scale plus number formatting are not applied to computed fields. That is a platform defect, tracked at objectstack-ai/objectstack#10280; nothing to fix here.

---

Found by driving the app as a sales manager in a browser on 17.1.0.

[huangyiirene]

Triage (代扫, vacancy clause) → pm:queue. ⚠️ Scoped to the HISTORICAL rows only — the current quarter is excluded and belongs to #1212.

This card was filed 2026-08-23 with bug + metadata and no pm-state at all, so it has been invisible to every candidate query for two days. The triage seat (objectstack#6015) does not cover hotcrm; acting under the vacancy clause, triage actions only. type left alone — this repo still has no type producer.

Premise re-verified against origin/main @ f685136, not quoted forward from the card

$ git grep -n "pipeline_amount:" origin/main -- src/data/
src/data/revenue.seed.ts:342:  pipeline_amount: 0,
src/data/revenue.seed.ts:381:      pipeline_amount: 760000,
src/data/revenue.seed.ts:396:      pipeline_amount: 0,

The two zeroed sites and the single real row are all exactly where the card says. Last commit to touch the file (d511b67) was a copyright-header gate, not the data. Premise holds.

⛔ The card's "worth checking at the same time" paragraph is OUT of scope, and this is load-bearing

The body says: "Worth checking at the same time whether the seeded periods should include the current quarter." ⛔ They must not, and this card must not touch that window.

#702 ruled that the current quarter has exactly one producer — the scheduled forecast_snapshot sweep. src/flows/demo-bootstrap.flow.ts documents the dependency where it explains why it claims crm_forecast at all:

Claiming it is only CORRECT because the seeds no longer ship a row in the window forecast_snapshot owns (src/data/revenue.seed.ts).

So seeding the current quarter would put a second writer into a window a ruling deliberately closed — a regression dressed as a fix, and it would silently break demo-bootstrap's stated correctness condition. This is not my inference: it is the finding the maintainer recorded on #1212 on 2026-08-23 after checking it against origin/main, correcting that card's own stated cause.

⇒ The two cards are NOT one family and are not folded. They share a file and a symptom vocabulary and nothing else:

	this card (#1244)	#1212
window	historical periods (Q3/Q4 2025, Q1/Q2 2026, Jun/Jul 2026)	current quarter
producer	seeds, uncontested	the forecast_snapshot sweep, ruled sole owner by #702
nature	a defect — authored rows say 0 where the shape exists	a product question — what a first-boot demo should show before the first snapshot
state	pm:queue, dispatchable now	needs-user-decision, the maintainer's

Backfilling the historical rows is invariant restoration: those periods are over, no sweep will ever write them, and the object's own shape (760000 / 540000 / 360000 at :381) is already authored on one row and simply not applied to the rest. No ruling governs that window and nothing else writes it.

Independently checkable on delivery

commit_amount / best_case_amount / pipeline_amount non-zero in at least 6 of the 7 seeded snapshots, coverage_ratio computing to non-zero as a consequence, and zero rows added in the window forecast_snapshot owns — that last one is the guard against the excluded half sneaking in.

Not the fix and not to be chased here: the 106.07142857142857 / unseparated 1485000 rendering is a platform defect on computed-field scale, tracked at objectstack#10280.

---

Generated by Claude Code

[huangyiirene]

Claim: PM loop round 1
Session: session_01STpYzSP2LiZwZinh6m6Qgf
Branch: claude/issue-1244-forecast-seed-backfill
Worktree: hotcrm-issue-1244
Domain: (hotcrm has no domain:* taxonomy — repo-wide seat, objectstack#10282)
File surface: src/data/revenue.seed.ts, plus one test file for the pin — name it in the report (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Clause-②: no — seed data values only. No contract accept/reject behaviour changes, no public surface widens; this repo ships no packages.
Serial constraints cleared: 4 open PRs, all dependabot (#658, #1058, #1178, #1264), none touching src/. No open agent PR. Batch sibling #1185 takes src/flows/** + src/translations/** — disjoint. Batch sibling #734 half 1 / #760 is a live-console measurement plus at most src/views/opportunity.view.ts — disjoint. ⚠️ Read coupling to be aware of but not act on: #1212 concerns the same file but the opposite window and is in the decision inbox, ⛔ unclaimable and untouchable here.

Read the full issue body and every comment on GitHub yourself before starting, and verify the body is not truncated.

---

Ruling (⛔ not re-adjudicable) — the scope split

This card is the HISTORICAL periods only. ⛔ The current quarter is excluded, and the exclusion is load-bearing rather than tidiness:

#702 ruled the current quarter has exactly one producer — the scheduled forecast_snapshot sweep. src/flows/demo-bootstrap.flow.ts documents its own correctness as depending on that:

Claiming it is only CORRECT because the seeds no longer ship a row in the window forecast_snapshot owns (src/data/revenue.seed.ts).

So a seeded current-quarter row would put a second writer into a window a ruling deliberately closed and silently falsify demo-bootstrap's stated precondition. The card's own line — "Worth checking at the same time whether the seeded periods should include the current quarter" — is therefore ⛔ out of scope, and it is not my inference: the maintainer measured and recorded exactly this on #1212 on 2026-08-23, correcting that card's stated cause. #1212 is now needs-user-decision and that window is theirs.

⇒ If your fix would add or modify any crm_forecast row in the window forecast_snapshot owns, stop. That is the fork, and it is reported, not worked around.

PM mechanism assumptions (measured this round — falsify them and say so)

Verified against origin/main @ f685136, not quoted forward from the card:

src/data/revenue.seed.ts:342:  pipeline_amount: 0,
src/data/revenue.seed.ts:381:      pipeline_amount: 760000,   <- the one real row
src/data/revenue.seed.ts:396:      pipeline_amount: 0,

1. Two zeroed sites (:342, :396) and one fully-populated row (:381, 760000 / 540000 / 360000). The shape is already authored — this is applying an existing pattern, not inventing one. Read :381 and follow it.
2. Last commit to touch the file (d511b67) was a copyright-header gate, not the data. No recent churn to reconcile.
3. coverage_ratio is derived from pipeline_amount; the card says it computes itself once the numerator is non-zero. ⚠️ Verify that rather than assuming it — if it turns out to be a stored column that also needs seeding, say so.

PM's suggested route (optional — measurement beats it)

The card's guidance is sound: the arithmetic "does not have to be real, it has to be plausible and non-zero". Each historical period already carries a quota and a closed amount, so values consistent with those (pipeline ≳ best case ≳ commit, and commit landing near the closed figure for a period that actually closed) will read correctly to a sales manager. ⛔ Do not over-engineer this into a computation; it is demo data whose job is to demonstrate the columns.

Independently checkable on delivery

State each of these as a measured reading, not an assertion:

1. commit_amount / best_case_amount / pipeline_amount non-zero in ≥ 6 of the 7 seeded snapshots.
2. coverage_ratio non-zero as a consequence.
3. ⚠️ Zero rows added or changed in the window forecast_snapshot owns — the guard on the excluded half. Name how you checked.

Non-negotiable for this card

• Gates, read off package.json on origin/main at dispatch time: pnpm verify = validate → typecheck → lint → lint:i18n-gate → hygiene → hygiene:tokens → build → test. Exit codes captured after redirect, never through a pipe.
• ⚠️ hygiene:tokens is a shrink-only ratchet. This card adds authored bytes. Report headroom before/after and ⛔ never raise a ceiling — that is a maintainer ruling. Stop and report if you cannot fit.
• Changeset gate is live in this repo (changeset-check.yml, judged on a newly added .changeset/*.md diffed against the base sha; private: true does not exempt it). Legal escapes if this publishes nothing: the skip-changeset label, or a changeset with empty frontmatter.
• Reverse-verify the pin: ablate your seed change and show the new test goes red, from a committed state. ⚠️ Two traps recorded in this repo: ablating uncommitted edits loses them silently to the restore, and git checkout -- PATH restores from the index — use git checkout HEAD -- PATH and verify the tree afterwards.
• PR draft, base main, first body line Fixes #1244. ⚠️ A squash pulls commit subjects into the merge commit — keep Fixes out of commit subjects if you end up scoping to Part of.

Report

Terminal report as a comment on this issue first (first line the literal os-dev-report), then as the return message. Machine-checkable fields only. Also leave your own claim comment with your own session ID and branch — this one identifies the PM session, not you.

premise_still_valid: false with pr: null is a legitimate delivery.

---

Generated by Claude Code

[huangyiirene]

Claim: dev subagent (os-dev), dispatched by the PM seat above.
Session: session_01STpYzSP2LiZwZinh6m6Qgf (dev subagent, mode:subagent — distinct worker from the PM claim comment which carries the same session id)
Branch: claude/issue-1244-forecast-seed-backfill (pushed empty at f685136 as the write-route probe before the first edit)
Worktree: /home/user/hotcrm-issue-1244
Base: origin/main @ f685136
Scope taken: historical crm_forecast seed rows in src/data/revenue.seed.ts only. ⛔ The current-quarter window forecast_snapshot owns (#702, demo-bootstrap.flow.ts precondition) is untouched — that half is #1212's and stays in the decision inbox.
Assignee left alone (PM's claim). Report will land here as os-dev-report before the return message.

---

Generated by Claude Code

[huangyiirene]

os-dev-report

{
  "issue": 1244,
  "status": "done",
  "branch": "claude/issue-1244-forecast-seed-backfill",
  "pr": "https://github.com/objectstack-ai/hotcrm/pull/1281",
  "premise_still_valid": true,
  "summary": "Card premise re-verified on origin/main @ f685136 and it held exactly: 6 of the 7 seeded crm_forecast rows carried 0 in pipeline_amount/best_case_amount/commit_amount, and the 7th (demo_month_current, the :381 row) carried 760000/540000/360000. All six settled rows now carry the residual that was still open on their closing day, following the :381 shape rather than inventing one: cumulative order preserved (pipeline >= best_case >= commit, as forecast.object.ts defines the buckets and forecast-snapshot.flow.ts accumulates them) and deliberately smaller than each period's closed amount, so a settled row never reads like a mid-period book. The closedPeriod helper now takes them as a named OpenBuckets object instead of three more positional numbers. SCOPE GUARD: zero rows added or modified in the window forecast_snapshot owns - the diff changes only amount columns on rows that already existed and adds no record; the pre-existing #702 guards in the same test file ('no seeded forecast row lands inside that window', 'every seeded row in the swept period is SETTLED') stayed green on every run, including under the ablation. The card's current-quarter paragraph was not touched and #1212 is untouched. PM mechanism assumption 3 is PARTLY FALSIFIED and this corrects the card: coverage_ratio is indeed a formula field, but it does NOT simply follow pipeline_amount. Its expression is '(quota - closed) > 0 ? pipeline / (quota - closed) : 0.0' and its own description says 'Reads 0 once the quota is already met'; three seeded periods over-attained (106% / 109% / 105%), so their gap is negative and they read 0 for a reason no seed value can or should change. Measured through the field's own expression, non-zero coverage goes from 1 of 7 rows to 4 of 7 (3.71 / 2.74 / 3.00 / 2.00), and the remaining three zeros are meaning rather than absence. PM assumptions 1 and 2 held as stated.",
  "tests": "HEAD at every reading below: eff111a (worktree clean, git status empty). [1] FULL GATE UNION, at the final commit, under the shared lock, exit read off the lock's own verdict line rather than a pipe: `bash scripts/pm/os-verify-lock.sh -c 'pnpm verify'` -> 'os-verify-lock: VERDICT command-exit 0 - held the lock 154s (2m34s) - waited 0s'. pnpm verify is validate -> typecheck -> lint -> lint:i18n-gate -> hygiene -> hygiene:tokens -> build -> test (&&-chained, so the tests running at all proves every earlier gate exited 0). Suite line: ' Test Files  124 passed (124)' / '      Tests  2900 passed | 1 skipped (2901)'. [2] TARGETED PIN: `pnpm exec vitest run test/forecast-seeds.test.ts` -> 'Test Files 1 passed (1)' / 'Tests 23 passed (23)' = 17 pre-existing + 6 new. [3] REVERSE VERIFICATION, run from the COMMITTED state. Direction predicted before running: red on exactly the two new guards that encode the fix, green on the #702 window guards. Mutation: restore the zeros at all five closedPeriod call sites plus the inline demo_quarter_minus_1 row, keeping the new signature so any red is the assertion's and not a type error at the call sites. NO BUILD/DIST LEG IS NEEDED HERE AND THIS IS WHY: the test imports ../src/data/index which imports ./revenue.seed from SOURCE, vitest transforms the TS directly, and there is no dist in the resolution path - so a rebuild could not change what the run reads. MUTATION CONFIRMED ON DISK, not by the editor's exit code: injected-literal count 5/5 ('{ pipeline: 0, bestCase: 0, commit: 0 }'), remaining non-zero literals 0, and `git hash-object` moved the blob 3eb8370... -> c610645... (an empty or equal hash was scripted to abort the run). Observed: 'Tests 2 failed | 21 passed (23)' - red on 'no seeded snapshot ships a zeroed amount column' (18 findings = 6 rows x 3 columns, the card's exact measurement) and on 'coverage_ratio computes from the seeded pipeline - non-zero exactly where a gap remains'; all four #702 window guards green throughout. RESTORE: the script carried `trap restore EXIT INT TERM` with an absolute REPO_ROOT from `git rev-parse --show-toplevel`, restoring with `git checkout HEAD -- <abs path>` (never the bare form, which reads the index). Restore PROVEN by state, not by exit code: `git diff HEAD` empty, `git status --short` empty, and the worktree blob back to 3eb8370... identical to `git rev-parse HEAD:src/data/revenue.seed.ts`. Pin re-run green on the restored tree (23 passed). [4] RATCHET, hygiene:tokens - unmoved, and structurally so rather than by luck: the ratchet excludes src/data/ and src/translations/ from the measured surface entirely by maintainer ruling of 2026-08-17, quoted verbatim in scripts/check-source-token-ratchet.mjs. Measured on both trees with --json: business semantics 82220/85000, interaction layer 38411/42000, authored total 134558/140000 - byte-identical on base f685136 and on this branch. Headroom unchanged (2780 / 3589 / 5442 under). No ceiling approached and none raised. The new test lives under test/, also outside the measured surface. [5] CHANGESET: .changeset/forecast-seeds-carry-a-residual.md, newly added vs base f685136, 'hotcrm: patch'. No skip-changeset label involved. [6] NOT A FAILURE, recorded so nobody re-chases it: the verify log contains a line reading 'x i18n lint gate: objectstack lint --json output has no issues array ... Got keys: passed, total'. That is test/lint-i18n-gate.test.ts:163 driving the gate's own failure path with a fixture, captured into the log. Run in isolation, `pnpm lint:i18n-gate` prints the tick and exits 0 (measured). FILE SURFACE, as the dispatch asked me to name it: src/data/revenue.seed.ts (the implementation), test/forecast-seeds.test.ts (the one test file for the pin - the existing forecast seed guard file, extended with one #1244 describe block rather than a new file), .changeset/forecast-seeds-carry-a-residual.md. Three files, +215/-7.",
  "open_questions": [],
  "out_of_scope_findings": [
    "NOT FILED - filing channel unavailable from this seat, PM to file or wave off: test/forecast-seeds.test.ts:137-139 on origin/main reads 'these eight authored records' and 'the demo shows eight distinct periods' where the crm_forecast seed holds SEVEN (2 inline records + 5 closedPeriod calls). Pre-existing comment drift, above my appended block and untouched by this PR; harmless to behaviour, but it sits in the one file whose job is to state the seed's invariants precisely. Not filed because the dedupe search that must precede filing has no channel here: raw REST to api.github.com is refused from this dev seat (HTTP 403, 'GitHub access is not enabled for this session. An org admin must connect the Claude GitHub App for this organization.'), and the dispatch contract forbids MCP list_issues/search_issues for that read. Reporting rather than filing blind, and rather than withholding."
  ]
}

---

Generated by Claude Code