| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
(3d-32)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
recording (3d-30 B3)
|
| | |
|
| |
|
|
| |
(3d-30 A)
|
| | |
|
| |
|
|
| |
fields; 3d-29 (b05e728) does not build from a clean checkout without this
|
| |
|
|
| |
point-in-time valuation (3d-29)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
origin port conflict
|
| | |
|
| | |
|
| |
|
|
| |
(3d-25)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Expose a deterministic source key on booked dividend records and surface a read-only dividend history panel with empty state, backed by API tests and browser QA assertions.
|
| |
|
|
| |
Book cash dividends to available cash exactly once and reinvest dividends through the shared subscription pipeline, with deterministic scheme idempotency and cross-position isolation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First vertical slice for portfolio rebalancing. Domain gains
RebalancePolicy: target-allocation validation (non-empty, per-code
shares positive two-decimal, sum exactly 100); diff computation over
the union of target and held codes (held without target = full exit)
producing BUY amount diffs and SELL unit diffs priced at the current
valuation NAV, clamped to available units, with no orders when a
weight already balances; and the deterministic idempotency key set
(rebalance:{plan}:{date}:{code} plus confirm/redeem counterparts).
Rebalance plans persist as rebalance_plans + rebalance_targets with
rebalance_idempotencies under the shared replay/conflict contract.
ExecuteRebalancePlan snapshots cash plus holdings valued at each
position's latest valuation NAV, then walks the diffs SELL-first
through the same Create/Confirm pipeline used by manual orders,
redemptions and SIP (nothing bypasses confirmation; a held code
without a valuation is skipped with an explicit marker; insufficient
cash/units fail the period visibly instead of silently trimming).
API exposes POST/GET /funds/{id}/rebalance/plans and POST
.../plans/{id}/execute. The frontend adds an 08/REBALANCE panel with
target editing (two codes, sum must equal 100), a plan list with a
manual execute button and post-run outcome rows; executing refreshes
orders/positions so the new orders are immediately visible. Domain
tests cover split validation, diff orders, exit/clamp logic, key
determinism; API tests cover create/execute end-to-end; Web tests
cover decoding and stale-execution protection.
|
| |
|
|
| |
parseRebalancePlanCommand (3d-7)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Advance executes due periods as real subscription orders: each due
trade date claims a sip_executions row (PRIMARY KEY plan_id+trade_date
makes same-plan same-day runs atomic), places the order through
CreateSubscriptionOrder with a deterministic idempotency key
(sip:{plan}:{date}) and the period's trade date, then confirms through
the shared ConfirmSubscriptionOrder pipeline with key
sip-confirm:{plan}:{date} — identical freeze/fee/units math as manual
orders, nothing bypasses confirmation. Outcomes: succeeded,
pending_nav (cash stays frozen; later drives retry the confirmation
once the NAV lands), insufficient_cash (no order placed, period fails
visibly, reruns keep the marker), failed. Plans roll their
next_trade_date past the processed window and repeats of the same
endDate replay recorded executions instead of re-debiting.
Domain adds SipPolicy.advancePlan (due-date enumeration; weekends-only
trading-calendar approximation, noted in code). POST
/funds/{id}/sip/advance {endDate?, limit?} drives execution on demand
(no daemon). Plan responses/rows now carry last execution status/date;
front-end shows 已执行/待净值/现金不足 per plan. Optional
tradeDateOverride/anchorOverride keep manual flows untouched.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce scheduled-investment plans as a schedule-only slice with no
cash, position or NAV side effects. Domain gains SipPolicy: amount
validation (positive, two-decimal, overflow-checked), frequency
parsing/round-trip (weekly/biweekly/monthly), nextTradeDate generating
the next due trade date off the plan anchor with month-end clamping
and weekend roll-forward, plus the isDue/executionNetAmount contract
the future executor will implement (execution itself stays
unimplemented and is marked as such; nothing debits cash in this
slice).
Persistence stores plans in sip_plans with anchor/next trade dates and
sip_plan_idempotencies under the shared replay/conflict contract; the
API exposes POST/GET /funds/{id}/sip/plans behind the bearer token.
The frontend adds a 07/SIP panel (code, amount, frequency select,
plan list with next debit date) and Web tests cover decoding,
validation, in-flight guards and stale completions. Choice note:
first debit is scheduled strictly after the anchor date (creating a
plan today never debits today).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Deposits credit a fund's available cash directly: Domain gains
CapitalPolicy (positive, two-decimal, overflow-checked amounts plus a
settle function that never touches units, NAV or realized P&L).
Persistence records deposits in fund_capital_deposits with a
fund_capital_idempotencies table, crediting cash and the deposit row
atomically under the same replay/conflict semantics as orders. The
API exposes POST /funds/{id}/capital/deposit and GET
/funds/{id}/capital/deposits behind the bearer token and idempotency
keys. The frontend adds an '追加资金' entry on the fund cash card with
in-place balance refresh, and repeats of the same amount reuse the
idempotency key so double submits credit cash exactly once. Browser
QA extends the J-series (J12-J18): invalid-amount rejection without
POST, single credited deposit with a 32-hex key, instant balance
refresh, unchanged units/cost proving no realized-income impact, and
same-key replay crediting only once.
|
