feat(phoenix): add Eternal state preparation - #9
Conversation
|
|
|
|
fdd0f55 to
ecdbc0c
Compare
bfecef3 to
eb85f90
Compare
eb85f90 to
6f4a50f
Compare
6f4a50f to
ca1c453
Compare
ca1c453 to
6f864e5
Compare
| pub fn new() -> Self { | ||
| let local = format!( | ||
| "http://127.0.0.1:{}", | ||
| CHANGE_TO_DEFAULT_STUDIO_PORT_ONCE_SUPERVISOR_MERGED | ||
| ); | ||
| Self::with_urls(local.clone(), local) |
There was a problem hiding this comment.
Standalone staging ignores configured port
When standalone surfpool mcp is used with a Studio server on a non-default --studio-port, Surfpool::new() still targets 127.0.0.1:18488, causing Phoenix scenario staging to post to the wrong server and fail.
Knowledge Base Used: MCP server integration
Prompt To Fix With AI
This is a comment left during a code review.
Path: crates/mcp/src/surfpool/mod.rs
Line: 179-184
Comment:
**Standalone staging ignores configured port**
When standalone `surfpool mcp` is used with a Studio server on a non-default `--studio-port`, `Surfpool::new()` still targets `127.0.0.1:18488`, causing Phoenix scenario staging to post to the wrong server and fail.
**Knowledge Base Used:** [MCP server integration](https://app.greptile.com/limechain/-/custom-context/knowledge-base/limechain/surfpool/-/docs/mcp-server.md)
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.6f864e5 to
9cf8066
Compare
|
@greptileai This axis is intentionally reverted to the established team convention: the MCP tools use the shared default-port constant inline, exactly as the pump tool on the base branch does. The constant's own name (CHANGE_TO_DEFAULT_STUDIO_PORT_ONCE_SUPERVISOR_MERGED) is the tracked follow-up — runtime addresses arrive with the supervisor work, for every tool at once, rather than piecemeal per PR. A non-default Studio port is not a supported configuration today anyway: the dashboard's own /config fetch breaks on it, independent of MCP. Standalone surfpool mcp has no configuration channel at all (the command takes no flags), so the constant is that mode's contract by construction. So please check your score as I believe is unproper 4/5 |
|
That context is valid. Given the current contract, the inline |
9cf8066 to
989d4bd
Compare
1d5ce77 to
cd94ac3
Compare
…lateral Move collateral, direct-mark, and reference scenarios onto the generic IDL override path and drop the bespoke forge for the parts the IDL can name. Fetch the market catalog live via list_phoenix_markets instead of hardcoding it. Write a hot trader's effective collateral into GlobalTraderIndex, where the risk engine actually reads it, not the stale copy in the Trader account. Remove the dead cascade example and editor schema and trim the builder.
…tion A Phoenix override with a bad value returned an error out of materialize_overrides_for_slot, which the block-production runloop turned into a simnet abort. Every Phoenix branch now warns with the override id and continues, like the shared IDL path. - dispatch the PerpAssetMap writer on the account discriminant, so the other Phoenix account types keep the generic IDL path - fill the fork gap once for GlobalConfig and the trader index instead of refetching per override - log the skipped same-slot refresh at warn - validate dynamic_ref values in create_scenario and say which tool resolves them - assert the templates' PerpAssetMap address against GlobalConfig in the live suite; keep every retry error in the live fetch helper
e5c5bcc to
204c28a
Compare
Adds declarative state preparation for Phoenix Eternal:
The implementation prepares protocol state only. It does not
build or execute trading or liquidation transactions.
Verification
Stacking
This PR is stacked on
feat/pump-protocol.Once the Pump PR is merged into
develop, this branch will be rebased and retargeted todevelop.Greptile Summary
The PR adds Phoenix Eternal state-preparation templates, typed account mutation, live market discovery, and MCP builders.
Confidence Score: 4/5
The PR is not yet safe to merge because MCP scenario staging remains unreachable with supported non-loopback, IPv6-only, or non-default-port Studio configurations.
The current staging path still posts every generated scenario to a hardcoded IPv4 loopback address and default port, so several previously reported supported deployment configurations cannot create Phoenix scenarios.
Files Needing Attention: crates/mcp/src/surfpool/mod.rs, crates/cli/src/http/mod.rs
Important Files Changed
Sequence Diagram
sequenceDiagram participant Client participant MCP as Surfpool MCP participant Surfnet participant Studio Client->>MCP: Build Phoenix scenario MCP->>Surfnet: Fetch live Phoenix accounts Surfnet-->>MCP: Account state MCP->>MCP: Validate and construct overrides MCP->>Studio: POST /v1/scenarios Studio-->>MCP: Scenario id MCP-->>Client: Editor URLReviews (20): Last reviewed commit: "fix(phoenix): skip rejected overrides in..." | Re-trigger Greptile