Skip to content

Stage content disclosure policy #440

Description

@ypldan

QuickApps version

latest

What is the problem this feature will solve?

Tool stages are a second, user-visible output channel: stage wrappers render request/response detail — including upstream error bodies — directly into the UI. How much backend/upstream detail an end user should see has never been decided deliberately, and it should stay consistent with the server-side content policy (#434).

What is the feature you are proposing to solve the problem?

A deliberate disclosure policy for stage content, aligned with the merged error-protocol design (#411 / PR #412):

  • Tool name and outcome always visible; request/response detail governed by the existing features.stage_display.level machinery; upstream error bodies summarized rather than shown raw.
  • Applied uniformly across the concrete stage wrappers (REST, MCP, deployment, files, skills, py-interpreter, …).
  • User-facing stages carry the error reference; the detail stays in server logs.

Design-first: one design addendum, then one implementation PR.

What alternatives have you considered?

Stripping stages down globally — stages are a transparency feature; the goal is deliberate disclosure, not minimal disclosure. Folding this into #436 — different channel and audience; product-facing behavior deserves its own review.

Additional information

Deliberately last in the epic. Related: #411 (error protocol, delivered in PR #412).

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions