Prepare socketry-project 0.3.6.

Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "socketry-project"
-version = "0.3.5"
+version = "0.3.6"
 edition = "2024"
 license = "MIT"
 repository = "https://github.com/socketry/socketry-project-rust"
@@ -26,6 +26,7 @@ bake = ">=0.19.0"
 bake-agent-context = { version = ">=0.2.0" }
 bake-cargo = { version = ">=0.4.0" }
 bake-license = { version = ">=0.1.1" }
+bake-markdown = { version = ">=0.3.0" }
 bake-readme = { version = ">=0.1.1" }
 bake-releases = { version = ">=0.2.1" }
 bake-test-rust = { version = ">=0.3.0" }

bake/Cargo.toml

@@ -6,5 +6,5 @@ publish = false
 
 [dependencies]
 bake = "0.19.0"
-bake-markdown = "0.2.0"
-socketry-project = { path = "..", version = "0.3.5" }
+bake-markdown = "0.3.0"
+socketry-project = { path = "..", version = "0.3.6" }

bake/src/bake_generated_tasks/mod.rs

@@ -1,4 +1,6 @@
-// Generated by `cargo bake --regenerate`; do not edit.
+// Released under the MIT License.
+// Copyright, 2026, by Samuel Williams.
 
+// Generated by `cargo bake --regenerate`; do not edit.
 use bake_markdown as _;
 use socketry_project as _;

context/conventions.md

@@ -1,92 +1,47 @@
 # Socketry Rust Conventions
 
-Use these conventions for Rust repositories in the Socketry organization. A
-project's local `.agents/` files and package-specific documentation can add
-requirements for that repository.
+Use these conventions for Rust repositories in the Socketry organization. A project's local `.agents/` files and package-specific documentation can add requirements for that repository.
 
 ## Repository and package boundaries
 
-- Use a separate repository when packages need independent versions, release
-  notes, or tags.
-- Keep packages in one workspace when they are intentionally released together:
-  use one shared version, one root `releases.md`, and one `vVERSION` tag.
-- Name crates for their public purpose. Use the `socketry-` prefix where needed
-  to identify Socketry packages in the flat crates.io namespace; keep Rust
-  module paths semantic and concise.
-- Use Cargo's standard `src/`, `tests/`, and `examples/` directories. Use
-  integration tests for public behavior across crate boundaries.
+- Use a separate repository when packages need independent versions, release notes, or tags.
+- Keep packages in one workspace when they are intentionally released together: use one shared version, one root `releases.md`, and one `vVERSION` tag.
+- Name crates for their public purpose. Use the `socketry-` prefix where needed to identify Socketry packages in the flat crates.io namespace; keep Rust module paths semantic and concise.
+- Use Cargo's standard `src/`, `tests/`, and `examples/` directories. Use integration tests for public behavior across crate boundaries.
 
 ## Crate and module paths
 
-Treat the Cargo crate name as the root namespace. Do not repeat it with a
-same-named top-level module. Keep modules for meaningful domain concepts, and
-re-export the main public API from the crate root when deeper modules only
-organize its implementation. For example, callers can import the
-agent-context API from the root:
+Treat the Cargo crate name as the root namespace. Do not repeat it with a same-named top-level module. Keep modules for meaningful domain concepts, and re-export the main public API from the crate root when deeper modules only organize its implementation. For example, callers can import the agent-context API from the root:
 
 ```rust
 use bake_agent_context::{ContextIndex, Installer, install_skills, list_skills};
 ```
 
-Keep public paths independent of redundant namespace layers such as
-`bake_agent_context::context`. Public modules remain useful when they name a
-real part of the API: a crate named `protocol_http` can expose
-`protocol_http::headers::AcceptHeader`, where `headers` identifies the domain
-concept within the crate.
+Keep public paths independent of redundant namespace layers such as `bake_agent_context::context`. Public modules remain useful when they name a real part of the API: a crate named `protocol_http` can expose `protocol_http::headers::AcceptHeader`, where `headers` identifies the domain concept within the crate.
 
 ## Source naming
 
-- Use `snake_case` for modules, source files, functions, methods, and variables.
-  Use `UpperCamelCase` for structs, enums, traits, and type parameters.
-- Preserve established initialisms in type and trait names: write
-  `HTMLRenderer`, `HTTPClient`, and `URLParser`, rather than
-  `HtmlRenderer`, `HttpClient`, or `UrlParser`. Keep filenames lowercase
-  `snake_case`, such as `html_renderer.rs`, `http_client.rs`, and
-  `url_parser.rs`.
-- Make public type and trait names fully descriptive; include the kind of thing
-  being named instead of relying on the module path to supply it. For example,
-  use `io_stream::BufferedStream` rather than `io_stream::Buffered`.
-- Prefer clear, consistent names. Avoid abbreviations unless they are an
-  established domain initialism or required by an external API.
-- Give each primary public struct, enum, or trait its own source file, named
-  after the item using lowercase `snake_case`. Keep small, closely related
-  helper types alongside it when that makes the code easier to understand.
+- Use `snake_case` for modules, source files, functions, methods, and variables. Use `UpperCamelCase` for structs, enums, traits, and type parameters.
+- Preserve established initialisms in type and trait names: write `HTMLRenderer`, `HTTPClient`, and `URLParser`, rather than `HtmlRenderer`, `HttpClient`, or `UrlParser`. Keep filenames lowercase `snake_case`, such as `html_renderer.rs`, `http_client.rs`, and `url_parser.rs`.
+- Make public type and trait names fully descriptive; include the kind of thing being named instead of relying on the module path to supply it. For example, use `io_stream::BufferedStream` rather than `io_stream::Buffered`.
+- Prefer clear, consistent names. Avoid abbreviations unless they are an established domain initialism or required by an external API.
+- Give each primary public struct, enum, or trait its own source file, named after the item using lowercase `snake_case`. Keep small, closely related helper types alongside it when that makes the code easier to understand.
 
 ## Consistency across packages
 
-Before introducing a new semantic, layout, or naming pattern, check how related
-Socketry packages handle the same concern. Reuse an established pattern when it
-fits the package's purpose. When a package establishes or changes a pattern,
-document the rationale and intended usage in that package's context so later
-work has a reference. Preserve differences that reflect real domain needs;
-consistency should make related packages easier to understand, not flatten
-their APIs into one shape.
+Before introducing a new semantic, layout, or naming pattern, check how related Socketry packages handle the same concern. Reuse an established pattern when it fits the package's purpose. When a package establishes or changes a pattern, document the rationale and intended usage in that package's context so later work has a reference. Preserve differences that reflect real domain needs; consistency should make related packages easier to understand, not flatten their APIs into one shape.
 
 ## Source and documentation
-- Keep authored repository-root Markdown files to lowercase `readme.md`,
-  `license.md`, and `releases.md`.
+
+- Keep authored repository-root Markdown files to lowercase `readme.md`, `license.md`, and `releases.md`.
 - Start `license.md` with `# MIT License`.
-- Keep `readme.md` human-focused: explain the project, its motivation when
-  useful, how to use it, recent releases, and how to contribute. Follow the
-  `Readme Structure` guide supplied by `bake-readme`.
-- Put reusable, package-specific agent guidance in `context/`; keep
-  repository-only instructions and project-owned skills in `.agents/`. Treat
-  the root `agents.md` as repository-owned guidance.
-- Avoid duplicating Rust-wide guidance from `bake-agent-context`; add project
-  context for the architecture and decisions that are specific to the crate.
-- Follow the Agent Context section in `readme.md` to install and discover
-  shared context and skills. The `bake-agent-context` guide explains the
-  installer's behavior.
+- Keep `readme.md` human-focused: explain the project, its motivation when useful, how to use it, recent releases, and how to contribute. Follow the `Readme Structure` guide supplied by `bake-readme`.
+- Put reusable, package-specific agent guidance in `context/`; keep repository-only instructions and project-owned skills in `.agents/`. Treat the root `agents.md` as repository-owned guidance.
+- Avoid duplicating Rust-wide guidance from `bake-agent-context`; add project context for the architecture and decisions that are specific to the crate.
+- Follow the Agent Context section in `readme.md` to install and discover shared context and skills. The `bake-agent-context` guide explains the installer's behavior.
 
 ## Development and releases
 
-- Keep development tasks in a private `bake/` package. Depend on
-  `socketry-project` there so task tooling does not become a runtime dependency
-  of the published library.
-- Use the `cargo:after_version_bump` hook registered by `socketry-project` to
-  update `license.md`, `releases.md`, and the generated sections of `readme.md`,
-  then normalize those files and all Markdown under the public `context/`
-  directory.
-- Follow the `socketry-project-releasing` skill to prepare and publish a
-  release. It links to Bake Cargo task documentation for workflow setup,
-  trusted publishing, reviewers, and tag creation.
+- Keep development tasks in a private `bake/` package. Depend on `socketry-project` there so task tooling does not become a runtime dependency of the published library.
+- Use the `cargo:after_version_bump` hook registered by `socketry-project` to update `license.md`, `releases.md`, and the generated sections of `readme.md`, then normalize those files and all Markdown under the public `context/` directory.
+- Follow the `socketry-project-releasing` skill to prepare and publish a release. It links to Bake Cargo task documentation for workflow setup, trusted publishing, reviewers, and tag creation.

context/github-repository.md

@@ -5,76 +5,52 @@ description: Create or maintain GitHub repository metadata, collaboration featur
 
 # GitHub Repository Setup
 
-Use these defaults when creating a Socketry repository. Preserve deliberate
-project-specific settings when maintaining an existing repository.
+Use these defaults when creating a Socketry repository. Preserve deliberate project-specific settings when maintaining an existing repository.
 
 ## Repository metadata
 
 - Use the canonical Socketry organization and project name.
 - Write a short, accurate repository description.
 - Set the homepage to the documentation site when one exists.
-- Add focused topics for discovery; avoid repeating words already in the
-  repository name.
+- Add focused topics for discovery; avoid repeating words already in the repository name.
 - Use `main` as the default branch.
 
 ## Collaboration features
 
-Enable Issues, Discussions, Pull Requests, Sponsorships, and repository
-preservation. Disable Projects and Wiki unless the project has a concrete use
-for them.
+Enable Issues, Discussions, Pull Requests, Sponsorships, and repository preservation. Disable Projects and Wiki unless the project has a concrete use for them.
 
 Use GitHub issue types to classify issues consistently:
 
 - `Bug` for defects and regressions.
 - `Feature` for new user-facing capabilities.
 - `Task` for maintenance, refactoring, documentation, tests, and release work.
 
-Prefer organization or repository labels that already exist. Add labels only
-when the project needs a reusable classification not covered by issue types or
-existing labels. Do not repeat issue type information in issue text when GitHub
-already records it as metadata. Issue types apply to issues; do not assign one
-to a pull request or include issue type information in its text.
+Prefer organization or repository labels that already exist. Add labels only when the project needs a reusable classification not covered by issue types or existing labels. Do not repeat issue type information in issue text when GitHub already records it as metadata. Issue types apply to issues; do not assign one to a pull request or include issue type information in its text.
 
 ## Pull requests and commits
 
 - Disable merge commits; allow squash and rebase merging.
-- Suggest updating pull request branches, allow auto-merge, and delete merged
-  head branches automatically.
-- Require contributors to sign off on commits made through GitHub's web
-  interface.
+- Suggest updating pull request branches, allow auto-merge, and delete merged head branches automatically.
+- Require contributors to sign off on commits made through GitHub's web interface.
 - Allow comments on individual commits.
-- Use Markdown, complete sentences, and a final period for pull request titles
-  and commit messages.
+- Use Markdown, complete sentences, and a final period for pull request titles and commit messages.
 - Keep most commit messages to one line. Start with what changed.
-- Describe pull requests with a short summary followed by the problem and
-  solution. Do not add a separate change type section or assign an issue type
-  to a pull request.
+- Describe pull requests with a short summary followed by the problem and solution. Do not add a separate change type section or assign an issue type to a pull request.
 
-Use the `socketry-project-pull-requests` skill for the full title, commit,
-description, testing, and release note conventions.
+Use the `socketry-project-pull-requests` skill for the full title, commit, description, testing, and release note conventions.
 
 ## Branch protection
 
-Protect `main` and require pull requests with at least one approval. Allow
-administrators to bypass these rules for maintenance. Require only stable
-checks that are needed for safe auto-merge; do not make experimental,
-informational, or unreliable coverage checks mandatory.
+Protect `main` and require pull requests with at least one approval. Allow administrators to bypass these rules for maintenance. Require only stable checks that are needed for safe auto-merge; do not make experimental, informational, or unreliable coverage checks mandatory.
 
 ## Apply settings safely
 
-Use the GitHub CLI for repository changes. Inspect the target first and always
-use its full name in commands:
+Use the GitHub CLI for repository changes. Inspect the target first and always use its full name in commands:
 
 ```sh
 gh repo view socketry/PROJECT
 ```
 
-When maintaining an existing repository, inspect its current settings and make
-the smallest change that achieves the intended result. Preserve project-specific
-settings. Do not rename, archive, transfer, or delete a repository without
-explicit approval, and do not disable issues, pull requests, or required checks
-without approval.
+When maintaining an existing repository, inspect its current settings and make the smallest change that achieves the intended result. Preserve project-specific settings. Do not rename, archive, transfer, or delete a repository without explicit approval, and do not disable issues, pull requests, or required checks without approval.
 
-The `socketry-project-releasing` skill describes the standard Cargo release
-process and links to Bake Cargo task documentation for branch rulesets,
-crates.io environment reviewers, and trusted publishing.
+The `socketry-project-releasing` skill describes the standard Cargo release process and links to Bake Cargo task documentation for branch rulesets, crates.io environment reviewers, and trusted publishing.