Skip to content

Publish Frame Vec<u8> inventory docs and recover ExecPlan#522

Merged
leynos merged 4 commits intomainfrom
compile-inventory-docs-yjpny6
Apr 12, 2026
Merged

Publish Frame Vec<u8> inventory docs and recover ExecPlan#522
leynos merged 4 commits intomainfrom
compile-inventory-docs-yjpny6

Conversation

@leynos
Copy link
Copy Markdown
Owner

@leynos leynos commented Apr 11, 2026

Summary

  • Compile and publish the inventory trait bounds documentation for Frame = Vec, including recovering Issue 287 ExecPlan context to bound the migration scope for frame/payload ownership.
  • This is a docs-only change focused on inventory, planning artifacts, and cross-links.

Changes

Documentation

  • Added docs/execplans/issue-287-inventory-trait-bounds-expecting-frame-vec-u8.md — ExecPlan for Issue 287 detailing constraints, taxonomy, risks, validation, and plan of work.
  • Added docs/frame-vec-u8-inventory.md — Inventory of Frame = Vec trait bounds and APIs, including taxonomy (frame-bound, payload-bound, internal-only, docs/tests-only) and confirmed runtime surfaces.
  • Updated docs/contents.md — linked the new frame-vec-u8 inventory to improve discoverability.
  • Updated docs/adr-001-multi-packet-streaming-response-api.md — clarified wording around channel constructors in the server-side multi-packet API documentation.
  • Updated docs/v0-2-0-to-v0-3-0-migration-guide.md — refined table formatting and wrapping for better readability; adjusted several root-path migration entries and notes.

Rationale

  • The repository previously recovered the missing Issue 287 ExecPlan from history and published the final inventory document (frame-vec-u8-inventory.md). This PR formalizes that work, providing:
    • A stable reference for what constitutes a frame-bound vs. payload-bound surface.
    • A clear plan for how to generalize transport frames without prematurely constraining payload APIs.
    • Documentation gates that help coordinate epic 284/284-era migration efforts.
  • Making these docs explicit helps maintainers and downstream users align on scope, risk, and next steps without introducing code changes.

Validation and checks

  • This is a docs-only PR; no code changes.
  • Local validation performed:
    • Ran formatting and markdown lint gates as part of the docs quality checks (e.g., make fmt, make markdownlint). All gates pass for the included files.
  • Cross-link checks: new ExecPlan references the frame-u8 inventory; inventory doc references the runtime surfaces and categories described in the ExecPlan.

Testing plan

  • Review the new ExecPlan to ensure it matches the inventory document and does not introduce conflicting claims.
  • Confirm cross-links in contents.md and migration guide are accurate and navigable.
  • Ensure formatting conforms to project conventions (tables, headings, code blocks).

Notes for reviewers

  • No code changes were made; please focus on:
    • Accuracy and completeness of the ExecPlan and inventory taxonomy.
    • Consistency of terminology (frame-bound vs. payload-bound vs. internal-only).
    • Clarity of the plan of work and validation steps.

◳ Generated by DevBoxer


ℹ️ Tag @devboxerhub to ask questions and address PR feedback

📎 Task: https://www.devboxer.com/task/7afce1d8-b015-472e-b74a-57696a4c91ee

Summary by Sourcery

Add and publish documentation inventorying all remaining Frame = Vec<u8> trait bounds and APIs, restore the Issue 287 ExecPlan describing that inventory and migration context, and hook these docs into the existing documentation index while making minor readability tweaks to related guides.

Documentation:

  • Publish a detailed inventory of Frame = Vec<u8>-related trait bounds and payload APIs, including taxonomy, risks, and migration considerations.
  • Restore and finalize the Issue 287 ExecPlan document describing constraints, validation, and plan of work for the frame/payload migration scope.
  • Link the new inventory into the docs contents index and clarify wording/formatting in the multi-packet streaming ADR and v0.2.0→v0.3.0 migration guide for better readability.

…nd APIs

- Published comprehensive inventory documenting all code paths, trait bounds, implementations, and public/internal APIs that still assume or expose `Frame = Vec<u8>`, supporting epic 284 migration planning.
- Distinguished coupling categories: true frame-bound, payload-bound public API, internal-only runtime surfaces, and docs/tests-only references.
- Updated documentation index to include new frame-vec-u8-inventory.md.
- Cleaned up related multi-packet streaming response API docs.
- Revised migration guide to improve formatting and clarify moved types.
- Ensured documentation quality gates pass (formatting and markdown linting).

This addition bounds the migration scope clearly without prescribing any migration sequence, aiding subsequent generalization of transport frame and payload ownership abstractions.

Co-authored-by: devboxerhub[bot] <devboxerhub[bot]@users.noreply.github.com>
@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented Apr 11, 2026

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 2f6cb122-dc8f-4d0f-ab7c-bc0e64484c37

📥 Commits

Reviewing files that changed from the base of the PR and between f8fc30a and 72b7a27.

📒 Files selected for processing (2)
  • docs/frame-vec-u8-inventory.md
  • docs/v0-2-0-to-v0-3-0-migration-guide.md

Docs-only change: Frame = Vec inventory and Issue 287 ExecPlan

This pull request restores the Issue 287 ExecPlan and publishes a repository inventory of APIs and trait bounds that assume Frame = Vec, supporting epic 284 by bounding migration surface for transport-frame generalisation.

New documentation

  • ExecPlan for Issue 287 (docs/execplans/issue-287-inventory-trait-bounds-expecting-frame-vec-u8.md)
    A living ExecPlan that defines purpose, constraints, tolerances, risks, evidence requirements, acceptance/validation criteria, progress tracking and a decision log. Status: COMPLETE. The plan records recovered history, scanning rules, idempotence/recovery behaviour and an outcomes/retrospective.

  • Frame = Vec inventory (docs/frame-vec-u8-inventory.md)
    A taxonomy-driven inventory (frame-bound, payload-bound, internal-only, docs/tests-only) enumerating confirmed surfaces that still rely on owned Vec framing/payloads, adjacent migration constraints, test/docs exposures, and recommended workstreams for epic 284. Notes that top-level codec/protocol abstractions are no longer hard-coupled to F::Frame = Vec, and highlights remaining public payload-owned API migration scope.

Supporting changes

  • docs/contents.md: Added a Reference Guides entry linking to the Frame = Vec inventory for discoverability.
  • docs/adr-001-multi-packet-streaming-response-api.md: Minor reflow/clarification in the consequences wording around server-side channel constructors (no API changes).
  • docs/v0-2-0-to-v0-3-0-migration-guide.md: Formatting and line-wrapping refinements; table reflow and prose rewraps (no behavioural/API changes).
  • .gitignore: Added pattern to exclude .agents/mcp/context_pack/packs/.

Validation

  • Documentation-only changes; no code or public API modifications.
  • Local formatting and markdown linting were run (make fmt, markdownlint) and passed.
  • Cross-links added between the ExecPlan and the inventory; reviewers should focus on accuracy/completeness of the inventory taxonomy, terminology consistency, and clarity of the ExecPlan’s validation and workplan.

Walkthrough

Document the remaining uses of Frame = Vec with a new inventory and execplan, update the docs contents and migration guide formatting, and add a gitignore pattern to ignore agent context_pack packs.

Changes

Cohort / File(s) Summary
Configuration
\.gitignore
Add ignore pattern for .agents/mcp/context_pack/packs/.
Inventory & planning docs
docs/frame-vec-u8-inventory.md, docs/execplans/issue-287-inventory-trait-bounds-expecting-frame-vec-u8.md, docs/contents.md
Add comprehensive inventory of Frame = Vec<u8> surfaces, an execplan to track trait-bound evidence and progress, and register the new inventory in the docs contents.
Documentation reflow
docs/adr-001-multi-packet-streaming-response-api.md, docs/v0-2-0-to-v0-3-0-migration-guide.md
Reflow and rewrap prose and tables for readability; preserve API names and semantics (formatting-only changes).

Possibly related issues

Poem

📚 Track the frames where Vec\u003cu8\u003e hides,
Inventory laid out in tidy guides,
Migration notes rewrapped and clear,
Ignore the packs that need not appear,
Docs aligned — migration steers the rides.

🚥 Pre-merge checks | ✅ 7
✅ Passed checks (7 passed)
Check name Status Explanation
Title check ✅ Passed The title directly summarises the main changes: publishing the Frame Vec inventory documentation and recovering the Issue 287 ExecPlan, which are the primary objectives of this documentation-focused PR.
Description check ✅ Passed The description provides comprehensive context on the inventory and ExecPlan documentation additions, explaining rationale, validation steps, and requesting focused review on accuracy and terminology consistency.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Testing ✅ Passed PR comprises solely documentation modifications with no source code changes, therefore testing requirements do not apply.
User-Facing Documentation ✅ Passed This pull request introduces no new or changed user-facing functionality or behaviour — it contains exclusively documentation and configuration changes (.gitignore addition plus markdown content edits and reformatting). The PR publishes inventory documentation and an ExecPlan for tracking existing constraints around Frame = Vec trait bounds, but makes no modifications to the codebase or user-facing APIs. Since the precondition triggering this check requirement does not exist, the check passes by default.
Developer Documentation ✅ Passed Pull request contains purely documentation-only changes inventorying existing code coupling to Frame = Vec, with no new internal APIs, architectural boundaries, abstractions, tooling, or build requirements introduced.
Module-Level Documentation ✅ Passed The custom check regarding module-level docstrings applies exclusively to code modules. This pull request contains only documentation files (.md), configuration (.gitignore), and no code modules whatsoever.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch compile-inventory-docs-yjpny6

Comment @coderabbitai help to get the list of available commands and usage tips.

@sourcery-ai
Copy link
Copy Markdown
Contributor

sourcery-ai Bot commented Apr 11, 2026

Reviewer's Guide

Docs-only PR that restores and publishes the Issue 287 ExecPlan and a detailed Frame = Vec inventory document, wires them into the docs index, and makes small wording/formatting improvements to existing ADR and migration docs for clarity and readability.

Sequence diagram for middleware request/response flow in the Frame Vec_u8 inventory

sequenceDiagram
    participant CodecDriver
    participant FrameCodec
    participant InboundHandler
    participant Envelope
    participant Middleware as MiddlewareLayer
    participant Handler as RouteHandler
    participant Serializer

    CodecDriver->>FrameCodec: decode(raw_bytes)
    FrameCodec-->>CodecDriver: frame

    CodecDriver->>InboundHandler: frame
    InboundHandler->>Envelope: build_from_frame(frame)
    Envelope-->>InboundHandler: env

    InboundHandler->>Middleware: ServiceRequest::new(env.payload, env.correlation_id)
    Middleware-->>Middleware: frame_mut()/frame() edits Vec_u8

    Middleware->>RouteHandler: call(ServiceRequest)
    RouteHandler-->>Middleware: ServiceResponse::new(payload, correlation_id)

    Middleware-->>InboundHandler: ServiceResponse
    InboundHandler->>Envelope: PacketParts::new(env.id, resp.correlation_id(), resp.into_inner())
    Envelope-->>InboundHandler: outbound_env

    InboundHandler->>Serializer: serialize(outbound_env)
    Serializer-->>InboundHandler: Vec_u8

    InboundHandler->>FrameCodec: wrap_payload(Bytes::from(Vec_u8))
    FrameCodec-->>CodecDriver: outbound_frame
    CodecDriver-->>CodecDriver: send(outbound_frame)
Loading

File-Level Changes

Change Details Files
Add a detailed inventory document describing all current Frame = Vec trait bounds, APIs, and their migration implications.
  • Introduce a standalone Frame = Vec inventory doc that categorizes usages as frame-bound, payload-bound, internal-only, or docs/tests-only.
  • Document concrete code surfaces (files, symbols, signatures) relying on Vec, including middleware, packets, client hooks, serializer, and internal DLQ paths.
  • Capture adjacent constraints (e.g., actor/codec boundary), current generic capabilities, and non-prescriptive migration strategies and risks for epic 284.
  • Record coordination notes, validation commands, and how this inventory should be used to plan future migration work.
docs/frame-vec-u8-inventory.md
Restore and publish the Issue 287 ExecPlan to formalize the plan and status for the Frame = Vec inventory work.
  • Reintroduce the Issue 287 ExecPlan as a living document describing purpose, constraints, risks, validation, and plan of work for the Frame = Vec inventory.
  • Mark the ExecPlan as COMPLETE and align its narrative with the newly added inventory document and current repo layout.
  • Document surprises (missing plan file, reduced hard-coded Frame = Vec usage), decisions, and outcomes related to epic 284 scope definition.
  • Include explicit validation commands and idempotence guidance for re-running or extending the inventory work.
docs/execplans/issue-287-inventory-trait-bounds-expecting-frame-vec-u8.md
Improve discoverability of the new inventory by linking it from the main documentation contents.
  • Add a new entry to the docs contents index pointing to the Frame = Vec inventory.
  • Provide a short description of the inventory’s purpose in the contents for quick scanning by readers.
docs/contents.md
Clarify ADR wording around server-side multi-packet response helper constructors without changing semantics.
  • Reflow and slightly reword the ADR section that mandates documenting tuple-based server-side multi-packet response handlers.
  • Make the reference to Response::with_channel and Response::with_channel_and_initial clearer while keeping the client-side API scope unchanged.
docs/adr-001-multi-packet-streaming-response-api.md
Tidy and reflow sections of the v0.2.0 → v0.3.0 migration guide for readability while preserving technical guidance.
  • Rewrap long paragraphs and code-related sentences to be line-length friendly without altering meaning.
  • Reformat the "Removed root path → New path" table to align columns and improve legibility.
  • Clarify and reflow narrative text around unified error surface, serde bridge, WireframeApp construction, testing utilities, streaming APIs, connection pool diagrams, and tracing configuration.
  • Fix minor spacing/line-break issues in explanatory text and comments to match project documentation style.
docs/v0-2-0-to-v0-3-0-migration-guide.md

Assessment against linked issues

Issue Objective Addressed Explanation
#286 Create an analysis document that maps middleware (ServiceRequest/ServiceResponse) boundaries and data flow where Vec is expected, and identifies integration points that would be impacted by a change to a different frame type (e.g., Bytes).
#286 Within that analysis document, provide a brief, non-prescriptive discussion of conceptual adaptation strategies and next steps for migrating away from Vec, with linkage to the relevant epic for tracking.
#287 Produce a documented inventory of traits, impls, generics, and APIs that assume Frame = Vec<u8> or otherwise expose Vec<u8> as the frame/payload representation, including brief notes on generalisation paths and potential risks.
#287 Publish the inventory and its exec plan as part of the repository documentation, making it discoverable (e.g., from the docs index) and suitable as an input into the broader migration/epic planning and alignment.

Possibly linked issues


Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

codescene-delta-analysis[bot]

This comment was marked as outdated.

…move lock file

Co-authored-by: devboxerhub[bot] <devboxerhub[bot]@users.noreply.github.com>
codescene-delta-analysis[bot]

This comment was marked as outdated.

@leynos leynos changed the title Publish Vec<u8> inventory docs; recover Issue 287 ExecPlan Compile inventory trait bounds documentation Apr 12, 2026
…ysis

Add detailed inventory and analysis of middleware payload ownership APIs related to
Vec<u8> frames in docs/frame-vec-u8-inventory.md. Document middleware data flow,
integration points, risks, and conceptual adaptation strategies following issue 286
and PR 283. Clarify distinct epic 284 workstreams covering transport-frame
substitution and public payload APIs to guide migration toward Bytes-compatible
boundaries while maintaining developer ergonomics and minimal boilerplate.

Also update related coordination notes to reflect resolved direction for epic 284.

Co-authored-by: devboxerhub[bot] <devboxerhub[bot]@users.noreply.github.com>
@leynos leynos changed the title Compile inventory trait bounds documentation Publish Frame Vec<u8> inventory docs and recover ExecPlan Apr 12, 2026
codescene-delta-analysis[bot]

This comment was marked as outdated.

Copy link
Copy Markdown
Contributor

@sourcery-ai sourcery-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've found 3 issues

Prompt for AI Agents
Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="docs/frame-vec-u8-inventory.md" line_range="19" />
<code_context>
+| ----------------- | ---------------------------------------------------------------------------------------------------- | ----------------------------------------------------- |
+| `frame-bound`     | A trait, impl, or test uses `Vec<u8>` as a concrete frame type.                                      | High when the transport frame type changes.           |
+| `payload-bound`   | A public API exposes owned payload bytes as `Vec<u8>` without literally fixing `F::Frame = Vec<u8>`. | High for API compatibility, lower for codec plumbing. |
+| `internal-only`   | Runtime code carries `Vec<u8>` internally without exposing it as a stable API.                       | Medium; usually easier to change behind shims.        |
+| `docs/tests-only` | Examples, tests, and design text that still teach `Vec<u8>`-shaped framing.                          | Low runtime risk, but high drift risk.                |
+
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The acronym “API” is used without expansion; per the style guide uncommon acronyms should be defined on first use.

Consider expanding “API” on its first occurrence, for example “application programming interface (API)”, to comply with the requirement to define acronyms on first use.

<details>
<summary>Review instructions:</summary>

**Path patterns:** `**/*.md`

**Instructions:**
Define uncommon acronyms on first use.

</details>
</issue_to_address>

### Comment 2
<location path="docs/frame-vec-u8-inventory.md" line_range="238" />
<code_context>
+
+### `internal-only` runtime surfaces
+
+- `src/app/builder/core.rs` stores `push_dlq` as
+  `Option<mpsc::Sender<Vec<u8>>>`.
+- `src/app/builder/config.rs` exposes that internal channel through
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The acronym “dlq” (in `push_dlq`) is used without being expanded; it should be defined as “dead-letter queue (DLQ)” on first use.

Since DLQ is not a universally known term, please expand it at its first mention, for example “dead-letter queue (DLQ)”, and then you can keep using “DLQ” elsewhere in the docs.

<details>
<summary>Review instructions:</summary>

**Path patterns:** `**/*.md`

**Instructions:**
Define uncommon acronyms on first use.

</details>
</issue_to_address>

### Comment 3
<location path="docs/frame-vec-u8-inventory.md" line_range="377" />
<code_context>
+   byte APIs justify standardization.
+```
+
+[^adr-004]: See [ADR 004](adr-004-pluggable-protocol-codecs.md) for the
+    generic codec decision and the current `Bytes` default frame type.
+[^issue-286]: Middleware follow-up requested by
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The acronym “ADR” is introduced without expansion; it should be defined (e.g. “Architecture Decision Record (ADR)”) on first use.

Please expand ADR at its first mention, for example “Architecture Decision Record (ADR) 004”, to satisfy the requirement to define acronyms on first use.

<details>
<summary>Review instructions:</summary>

**Path patterns:** `**/*.md`

**Instructions:**
Define uncommon acronyms on first use.

</details>
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Comment thread docs/frame-vec-u8-inventory.md Outdated
Comment thread docs/frame-vec-u8-inventory.md Outdated
Comment thread docs/frame-vec-u8-inventory.md Outdated
@coderabbitai coderabbitai Bot added the Issue label Apr 12, 2026
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@docs/frame-vec-u8-inventory.md`:
- Around line 389-391: The footnote reference [^unified-path] uses an
absolute-ish href that doesn't resolve; update the link target in
docs/frame-vec-u8-inventory.md (the footnote block that currently points to
docs/execplans/9-3-1-fragment-adapter-trait.md) to a relative path from this
file such as ./execplans/9-3-1-fragment-adapter-trait.md so the link resolves
correctly; edit the footnote line that contains the href to replace the old path
with the new relative path.

In `@docs/v0-2-0-to-v0-3-0-migration-guide.md`:
- Around line 705-707: Fix the malformed method reference by removing the stray
space so the docs reference the symbol correctly: change the text from
"ObservabilityHandle:: counter" to "ObservabilityHandle::counter" where `Labels`
and `ObservabilityHandle` are mentioned so the method symbol
`ObservabilityHandle::counter` is resolvable.
- Around line 894-897: The doc incorrectly shows the generic type `P` for
ResponseStream's stream item; update the text to use the concrete frame type
used across the guide (e.g. change `Item = Result<P, ClientError>` to `Item =
Result<Frame, ClientError>`) so the description of ResponseStream,
futures::Stream, and its ownership/termination behavior matches the rest of the
docs and the actual type returned by ResponseStream.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 4f3b65dc-0a89-49a2-b446-e7e88b3add57

📥 Commits

Reviewing files that changed from the base of the PR and between 03e06e1 and f8fc30a.

📒 Files selected for processing (6)
  • .gitignore
  • docs/adr-001-multi-packet-streaming-response-api.md
  • docs/contents.md
  • docs/execplans/issue-287-inventory-trait-bounds-expecting-frame-vec-u8.md
  • docs/frame-vec-u8-inventory.md
  • docs/v0-2-0-to-v0-3-0-migration-guide.md

Comment thread docs/frame-vec-u8-inventory.md
Comment thread docs/v0-2-0-to-v0-3-0-migration-guide.md
Comment thread docs/v0-2-0-to-v0-3-0-migration-guide.md Outdated
…nd migration guide

- Improved wording for clarity and expanded abbreviations in frame-vec-u8-inventory.md
- Fixed formatting issues and link relative path for docs
- Corrected typos and code reference in migration guide
- These changes improve documentation accuracy and developer understanding without code behavior impact.

Co-authored-by: devboxerhub[bot] <devboxerhub[bot]@users.noreply.github.com>
@leynos leynos merged commit 7304e62 into main Apr 12, 2026
5 of 6 checks passed
@leynos leynos deleted the compile-inventory-docs-yjpny6 branch April 12, 2026 16:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Analysis: Inventory trait bounds expecting Frame = Vec<u8> Analysis: Middleware layer (ServiceRequest/ServiceResponse) dependency on Vec<u8>

1 participant