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

    Fields

    No fields configured for Feature.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions