[Blocker] Backend gaps blocking 100% pure member-first Invoke/Observe closeout for #340

[AbigailDeng]

Related

• parent frontend closeout: feat(console-web): Member-first Invoke flow and Studio closeout #340
• broader backend track: [Feature] Backend: member-first Studio APIs with stable published service per member #325
• umbrella issue: feat(console-web): Studio 重构 — Team Context + Member-first Workbench #322

Why this issue exists

#325 covers the broader backend member model work.

This issue is narrower on purpose:

it isolates the backend contract gaps that specifically block #340 feat(console-web): Member-first Invoke flow and Studio closeout from reaching a 100% pure member-first outcome on the current frontend deadline.

In other words:

• #340 can still ship a meaningful frontend closeout on top of the current legacy runtime/binding APIs
• but #340 cannot honestly become fully member-first end-to-end without the backend pieces below

本 issue 的 deadline 仅通过 GitHub Milestone due date 管理。

Current frontend reality

Today Studio Invoke/Observe still ultimately rely on:

• scopeId + serviceId + endpointId for invoke
• scopeId + serviceId + runId for runs / observe
• scope binding state as the main source of published contract truth

That means frontend can improve framing, navigation, handoff, and lifecycle continuity, but it still cannot make memberId the real authority of bind / invoke / observe.

Hard blockers for pure member-first #340

1. No authoritative memberId -> publishedServiceId mapping

Frontend currently has no backend-owned truth for:

• which published service belongs to the current member
• whether that mapping is stable across rename / rebuild / rebind

Without this mapping, frontend must keep using legacy serviceId semantics in places where product semantics want memberId.

2. No member-centric binding API

Missing backend APIs such as:

• GET /api/scopes/{scopeId}/members/{memberId}/binding
• PUT /api/scopes/{scopeId}/members/{memberId}/binding

Without these, Bind cannot truly mean:

publish the current member revision to that member's stable published service

Frontend must keep reading/writing scope/service binding state instead.

3. No member-centric invoke API

Missing backend APIs such as:

• POST /api/scopes/{scopeId}/members/{memberId}/invoke/{endpointId}
• POST /api/scopes/{scopeId}/members/{memberId}/invoke/{endpointId}:stream

Without these, Invoke can only call runtime through legacy scope/service routes.

That means Studio can look member-first, but the real invoke target is still resolved via service-level runtime semantics.

4. No member-centric runs / observe query API

Missing backend APIs such as:

• GET /api/scopes/{scopeId}/members/{memberId}/runs
• GET /api/scopes/{scopeId}/members/{memberId}/runs/{runId}

Without these, Observe cannot truly answer:

show me the runtime facts for the current member

It can only continue to interpret runs through legacy service/runtime paths.

5. No backend member roster / detail truth for Studio routing

Missing backend member-centric list/detail APIs mean frontend still has to infer or bridge member focus from workflow / script / published service facts.

That keeps route semantics unstable:

• route memberId cannot yet be the fully honest primary key
• deep link continuity across Build -> Bind -> Invoke -> Observe remains partly compatibility-driven

Deadline impact on frontend #340

This is the critical part.

If the backend items above are not available before the current #322 closeout milestone due date, frontend #340 can still finish a strong closeout, but only with a reduced truth level:

Frontend can still finish

• member-first Invoke page framing
• stable Bind -> Invoke handoff
• lifecycle gating fixes
• Team entry / Studio deep-link cleanup
• member-first Observe framing and staged empty states
• main regression coverage

Frontend cannot honestly claim

• route memberId is the true authority for invoke
• Bind is fully member-owned instead of scope/service-backed
• Observe is querying member-owned runtime history
• Studio no longer depends on legacy service-level runtime semantics

Practical risk to the deadline

If backend contract work slips, the likely outcome is:

1. frontend ships a compatibility-mode member-first closeout for feat(console-web): Member-first Invoke flow and Studio closeout #340
2. the final acceptance language for feat(console-web): Member-first Invoke flow and Studio closeout #340 must explicitly avoid promising a fully pure member-first runtime chain
3. there will still be follow-up work after the current closeout milestone to remove legacy service-first runtime assumptions

This is important because otherwise frontend may appear visually done while still carrying semantic debt that blocks final closure of #322.

Minimum backend deliverables that would unblock pure closeout

The minimum useful backend slice for #340 is smaller than the full #325 scope:

• authoritative memberId -> publishedServiceId read path
• GET /api/scopes/{scopeId}/members/{memberId}/binding
• PUT /api/scopes/{scopeId}/members/{memberId}/binding
• member-centric invoke route or equivalent backend resolver that lets frontend invoke by memberId
• member-centric runs query path for Observe

Acceptance for this blocker issue

• Backend contract gaps impacting pure member-first #340 are explicitly tracked in one place
• #340 can reference this issue to distinguish frontend closeout from backend semantic blockers
• team alignment is explicit on what can ship by the current closeout milestone due date vs. what still depends on backend

One-line outcome

If this issue is unresolved, #340 should be treated as a frontend closeout on top of legacy scope/service runtime semantics, not the final fully pure member-first backend truth.