Investor workspaces: the leftovers, built up to the owner's line (D494–D499)

[guillaumelauzier]

S1: Task for slot S07, moved from S16 at the owner's request (wave-9 item 10)

On main (f701a32). Not started. The investor Deals, Research, Portfolio and Network workspaces came from six PRs recorded as D460–D465. Session 1 reviewed only #871 (D465), and this slot owns all six now. D491–D493 were taken by other work, so this item's numbers start at D494.

First, read D460–D465 against the code. Anything they claim that the code does not do joins this item.

Then one PR per zone family (Deals, Research, Portfolio, Network), each built up to the owner's line. Canvas IDs are from design/canvases/integrated/Pages · Investor Deals.dc.html, … Research.dc.html, … Portfolio.dc.html and … Network.dc.html; the ops sit in frontend/src/workspaces/investorZoneActions.js.

• The DD "Blocking" half and the section-weighting editor (the investor gap map's item 16; D466 names both as held). Blocking overlaps the IC panel's queue (Session 15's original T6): ask on this issue before building it. The weighting editor is large and needs an owner decision: build to the line.
• ID1 Configure stages (:61); ID2 New batch run and Edit rubric (:78–79); IR1 Clear history (:252); IR4 theses (/research/markets); IP2 Parse review; IN3 Organizations, IN1 Add person (:208) and IN2 Offer one (:219). Build each up to its decision.
• ID1 Save view (:62) needs a store (zone_saved_views) that frontend/src/workspaces/partnerZoneActions.js:41 would also use: ask on this issue before creating it.
• IP1 Add follow-on (:169) stays admin-only.
• "Rationale required": POST /api/ic/:uid/vote still accepts a null rationale on an ordinary vote (cloudflare-worker/src/routes/ic.ts:626; D461 left the requirement as the owner's call). Refuse it, or record why not.
• IR2 New request (:263) and IR3 sit on research.ts's deals/* routes, which are slot S02's: leave the routes, and have the zone say what the button waits on.

Owner's line. Owner-decision items are built up to the line (standing rule (c)): everything that does not depend on the decision ships, and the screen and the PR body both name the decision still missing. Never invent the answer to one.

Never build the brief's item-7 figures (U1 per-subsidiary numbers, token margin, revenue per subsidiary, seat ids, guardrail counters by branch); LTV, subscription revenue, key reveal and expiry; or anything blocked on the owner or a credential. Where a screen implies one of these, it states the absence.

Tests. Every change ships with a test that fails on today's code; a regex over source text is not one. Mutation-check each assertion both ways.

Coordinate with. research.ts's deals/* routes are slot S02's. In ic.ts, edit only your lines: the IC roster and quorum are not this slot's.

Owns. For the zone family each PR covers: investorZoneActions.js, investorZoneFilters.js, the pages under frontend/src/pages/investor/, your lines of routes/deals.ts and routes/ic.ts, their tests, and that PR's D-entry.

Number. D494 onward (D494–D499), one per PR; take them in order and leave gaps rather than reuse. Any migration comes from your range (343–345 are unassigned); re-measure the highest migration on disk before naming one (369 on f701a32).

Done when. One green draft PR per zone family, one at a time. Each says "Part of" this issue, and the last one closes it. Follow AGENTS.md and CLAUDE.md.

---

Generated by Claude Code

[guillaumelauzier]

S1: Moved from slot S16 to slot S07, at the owner's request. Report on this issue as slot S07. Take it after #1015; the two share investorZoneFilters.js. If a PR needs a migration, use 345.

---

Generated by Claude Code

[guillaumelauzier]

STATUS
task: #1023   slot: S07   agent: Claude Code
branch: agent/claude-b/1023-investor-deals (first PR: Deals, D494)
state: IN_PROGRESS
files: investorZoneActions.js, investorZoneFilters.js, pages under frontend/src/pages/investor/, my lines of routes/deals.ts and routes/ic.ts, tests, D494
blockers: none for the parts below that do not wait on an answer
questions: three, below. Each is asked before building, as this issue says. I build everything else meanwhile.
tests: none yet
pr: none yet

1. DD "Blocking", which overlaps the IC panel's queue (Session 15's T6).

• A. Blocking is a flag on a DD finding (blocking: true). The IC panel reads it and shows "N blocking findings" beside the vote. There is no second queue.
• B. Blocking items live only in the IC panel's queue. The DD zone links to that queue and adds no flag of its own.
• C. Hold it until T6 is settled.

My pick: A. It is one store, and the IC panel can read from it.

2. The zone_saved_views store for ID1 "Save view". partnerZoneActions.js:41 would use the same store.

• A. Create zone_saved_views in migration 345: per user, per workspace and zone, a name, and the filter JSON. It is shared by the investor and partner zones.
• B. Keep saved views in the browser (localStorage), with no store. This is per device and the screen says so.
• C. Not now. The button says what it waits on.

My pick: A. Saved views should follow the user across devices, and one table serves both workspaces.

3. The section-weighting editor. The issue says it needs an owner decision. Who may change the weights?

• A. Each investor, for their own firm's scoring. Weights are stored per firm and the default stays the platform's.
• B. Only a Super Admin, platform-wide.
• C. Read-only for now. The editor shows the current weights and names the decision as missing.

My pick: C for this PR, built to the line, until you choose A or B.

---

Generated by Claude Code

[guillaumelauzier]

STATUS
task: #1023   slot: S07   agent: Claude Code
branch: agent/claude-b/1023-investor-deals
state: IN_PROGRESS
files: routes/ic.ts (vote rationale + commit-room rule), CommitZone.jsx, ICDecisionPage.jsx, investorZoneActions.js (Deals ops), tests, D494
blockers: none for the next families; the three questions above still wait on the owner
questions: the three above (1 Blocking, 2 zone_saved_views, 3 weighting editor)
tests: npm run build; npm run test:drift -> EXIT=0. 5 mutations each caught.
pr: https://github.com/AxalNetwork/StudioOS/pull/1120 (Deals family, D494, "Part of #1023")

The state stays IN_PROGRESS: this is the first of four zone-family PRs, and Research (D495), Portfolio (D496) and Network (D497) follow one at a time.

---

Generated by Claude Code

[guillaumelauzier]

STATUS
task: #1023   slot: S07   agent: Claude Code
branch: agent/claude-b/1023-investor-research (not pushed yet)
state: IN_PROGRESS
files: investorZoneActions.js (Research ops), the Research zone pages, routes/research.ts (ask history only), D-entry
blockers: Research waits on the two answers below; questions 1-3 above are still open
questions: 4 and 5, below
tests: none yet
pr: Deals merged as #1120 (D494). Research is next; I do Portfolio meanwhile and take the next D number for whichever PR opens first.

Deals (#1120) is merged. The Research family is IR1 Ask, IR2 Diligence, IR3 Benchmarking and IR4 Markets. Two of its items are product calls, so I'm asking them before I build.

• IR2 and IR3 decided nothing new: they wait on research.ts's deals/* routes (S02's), and their buttons will say so.

4. IR1 "Clear history" on /research/ask.

• Today: the op is unbuilt. Its note refuses it on purpose ("erasing a reader's own questions is the one irreversible act this page declines to offer"), but that was never a recorded decision.
• The canvas has a "Discarded" filter and a "Cited in a memo" one. So an answer can matter after the reader stops looking at it.

Options:

• A. Clear deletes the caller's own sessions and answers, except answers marked kept. A kept answer may be cited, and the reader un-keeps it first. Needs a confirm step and no migration.
• B. Clear hides rather than deletes: a cleared_at on the caller's sessions, and a "Show cleared" filter brings them back. Nothing is lost, and a cited answer stays traceable. Needs one column.
• C. Keep refusing. The button stays unbuilt, and the note becomes a recorded decision.

My pick: B. It gives the reader a clean history without destroying the record the canvas cares about.

5. IR4 "theses" on /research/markets. No store exists. The canvas draws a list of theses, each with:

• a state (active, parked or retired);
• what it has sourced (positions that came from it);
• a written read.

That needs a table, and a link from a deal to the thesis that sourced it. The deals table and research.ts's deals/* routes are S02's, so the link would live in a table of its own.

Options:

• A. Per investor: research_theses (uid, owner, title, state, read, state_changed_at) plus research_thesis_deals (thesis, deal), both in migration 345. "Sourced" counts the linked deals that reached the portfolio. deals itself is not touched.
• B. The same, but theses belong to the investor's firm (shared by its seats) rather than to one person.
• C. Hold IR4. The Markets zone keeps its sector views, and the button says theses wait on this answer.

My pick: A. It is the smallest store that makes the canvas's "a thesis that sources nothing is a retired thesis" true. A firm share (B) can be added on top later.

If 4B and 5A are both chosen, both go in migration 345, the number S1 gave this issue. Questions 1-3 (DD Blocking, zone_saved_views, the weighting editor) are still open from 4 October.

---

Generated by Claude Code

[guillaumelauzier]

More questions from reading the Portfolio and Network families against the code. Each item needs a store, or a rule about who may see whom, so I'm asking before building.

6. IP2 "Parse review" (/portfolio/updates). The canvas wants each update's KPIs extracted as editable proposals, with ambiguous figures flagged ("a team of ~12" → 12, flagged) and the batch cost shown before it runs. Today nothing extracts, and the page says "No parse-review state is stored".

• A. Build it: an AI task proposes KPI values from an update's text into a new proposals table. The investor accepts or edits each one, and only an accepted value reaches the record. Needs a migration number from S1.
• B. No AI: "Parse review" lists updates whose founder-entered KPI fields are missing or not numeric, for the investor to query. No new store.
• C. Hold. The page keeps stating the absence.

My pick: A, with the cost estimate shown before the batch runs, as the canvas does.

7. IN1 "Add person" (network/relationships). A tie is a request the other person accepts (D493), and POST /partnernet/relationships takes a numeric user id. Nothing lets an investor find a person without exposing a user directory.

• A. The picker offers only people the investor already shares a deal or data room with.
• B. Any platform user, by exact email only. No listing, and the same answer whether or not the person exists.
• C. Hold.

My pick: A. It opens no directory.

8. IN3 "Organizations" and IN2 "Offer one".

• IN3: a relationship stores two accounts, a type and a strength, and no firm, so the Organizations list is empty for everyone.
  • A. The author records an organisation on their side of a tie, like the private note. The zone groups by it.
  • B. It is derived from the other person's own profile field, if one exists.
  • C. Hold.
• IN2: offering an introduction between two of your accepted ties.
  • A. Reuse the existing intro_propositions flow.
  • B. Hold.

My picks: IN3 A, IN2 A.

Until these are answered, #1023's remaining families stay built to the line, and each button names what it waits on. Meanwhile I'm on my other S07 work.

---

Generated by Claude Code