dtoro
4b8e3f04ee
The dock now has a "propose" button that asks Socrates to suggest one
high-value structural change. He returns a structured payload (reasoning
+ ops + impactSummary) which renders as a ProposalCard inline in the
thread. Accept routes the ops through the same useApply() pipeline as
user-originated edits (optimistic local + persisted POST + server
reconciliation).
apps/web/lib/llm/prompts/socrates/propose.md
- Promoted verbatim from phase-0/src/prompts/.
apps/web/lib/llm/proposeChange.ts
- Server-side proposeChange() — calls the LLM with character + propose
prompts + trimmed model + active issues. JSON Schema uses oneOf per
op kind (Phase 0 lesson: small models need this to produce real op
shapes instead of cramming everything into the kind name).
- normalizeOps() converts the LLM-emitted op shapes into canonical
ModelOp[] (fills in property ids/multiplicity defaults, expands
satisfiedBy[] into RequirementRelation[], splits PropertyType union
per kind).
apps/web/lib/sysml/impact.ts
- Pure pre-apply impact analysis. Runs the ops through the same
applyOps() reducer locally, then diffs:
- structural: added / removed / changed elements (per kind)
- validation: issues created vs resolved (by canonical issue key)
- dep-graph blast radius (closure of touched element ids on the
post-apply graph)
Headline stats summarized as deltas (+1 block, −1 assoc, etc.) for
the proposal card.
apps/web/app/api/projects/[projectId]/socrates/propose
- POST: returns { reasoning, ops, impactSummary, meta }. Pure read of
the model — does not apply anything; client must POST /apply with the
same ops to commit.
apps/web/components/socrates/ProposalCard.tsx
- In-dock card: PROPOSAL tag + delta stats / reasoning / collapsible
ops list / Impact section (added/removed/changed) / Validation diff
(resolves ✓ / creates ⚠) / Accept + Reject. Disabled when impact
analysis flagged the apply as illegal.
apps/web/components/socrates/SocratesDock.tsx
- New "propose" button between the input field and send. Renders
ProposalCard for assistant turns of role "proposal". Accept calls
useApply(); on success the card collapses to a "✓ Applied" system
bubble. On apply failure the dock shows the structured error
messages.
- New "system" bubble role for apply confirmations + dismissals.
apps/web/components/diagram-canvas/DiagramCanvas.tsx
- Bug fix: new blocks/constraints arriving via the model→RF sync (e.g.
from accepted proposals) are now positioned to the right of the
existing layout instead of stacking at (0, 0) offscreen.
apps/web/lib/sync/ModelStore.tsx
- Bug fix / observability: background-POST failures and version
mismatches now log to the console with structured context instead of
being silently swallowed. The server's authoritative state still
replaces the optimistic local state on response, but the user can now
see why their accept appeared to do nothing (typically: page tab
was at version N but server had advanced to N+1).
2.2 KiB
2.2 KiB
Mode: Propose a model change
You are reviewing the existing model and the active findings (assumptions, risks, inconsistencies). The PM has asked you to propose ONE concrete change to the model.
Pick the highest-value change you can make. Examples:
- Remove a fabricated or unused element
- Add a missing actor or block that the seed clearly implies but the model didn't capture
- Add a missing constraint
- Add a missing requirement linked to specific blocks
- Remove a duplicate (e.g., a constraint already covered by a requirement, or vice versa)
- Add an association the model is missing
Output
Return a JSON object with:
reasoning— 1–3 sentences explaining what you propose to change and why. Reference specific element ids.ops— an array of operations. Each op is one of:{ "kind": "add-block", "block": { id, label, kind: 'system'|'actor'|'block', properties: [{name, type:{kind, values?}}] } }{ "kind": "remove-block", "blockId": "id" }(also removes dependent associations and references){ "kind": "add-association", "association": { id, fromBlockId, toBlockId, label, kind: 'association'|'composition'|'generalization' } }{ "kind": "remove-association", "associationId": "id" }{ "kind": "add-constraint", "constraint": { id, label, expression, appliesTo: ["blockId"] } }{ "kind": "remove-constraint", "constraintId": "id" }{ "kind": "add-requirement", "requirement": { id, tag, text, satisfiedBy: ["blockId"] } }{ "kind": "remove-requirement", "requirementId": "id" }
Rules
- Prefer SMALL changes. 1–4 ops is ideal. A proposal that rewrites half the model is too big.
- Do not propose cosmetic changes (label tweaks, position changes — those are auto-applied).
- Every id you reference (
blockId,associationId, etc.) must exist in the current model — except for ids you're creating in this same proposal. - If you can't see a high-value change worth proposing, return an empty
opsarray and explain why inreasoning.
Output schema
{
"reasoning": "string (1–3 sentences)",
"ops": [ /* array of op objects per the kinds above */ ]
}
Return ONLY the JSON object. No prose preamble, no code fences.