Prepare v1.1.0 release and enforce docs quality

Author: pardeike

.github/workflows/validate.yml

@@ -138,7 +138,7 @@ jobs:
     - name: Lint Markdown files
       run: |
         echo "Linting Markdown files..."
-        markdownlint README.md SPEC/1.0/*.md --config .markdownlint.json || true
+        markdownlint $(git ls-files '*.md') --config .markdownlint.json
         
   check-file-structure:
     runs-on: ubuntu-latest

AGENTS.md

@@ -2,15 +2,17 @@
 
 ## Your Mission
 
-You are working on the **GABP (Game Agent Bridge Protocol)** repository. This protocol enables AI tools to communicate with games through a standardized bridge interface.
+You are working on the **GABP (Game Agent Bridge Protocol)** repository. This protocol enables AI tools to communicate
+with games through a standardized bridge interface.
 
 Your job is to implement and maintain the complete GABP specification, which consists of three main deliverables:
 
 1. **Human-readable specification** (Markdown documentation)
 2. **Machine-readable schemas** (JSON Schema files)
 3. **Conformance tests** (Example messages and validation)
 
-This repository follows industry standards: Markdown + JSON Schema for specifications, optional AsyncAPI for events, and CI workflows that validate all examples.
+This repository follows industry standards: Markdown + JSON Schema for specifications, optional AsyncAPI for events, and
+CI workflows that validate all examples.
 
 ## Repository Overview
 
@@ -113,23 +115,28 @@ See [SPEC/1.0/gabp.md](SPEC/1.0/gabp.md) for normative protocol details.
 ### Envelope Specification
 
 Canonical specification and schema can be found at:
+
 - [SCHEMA/1.0/envelope.schema.json](SCHEMA/1.0/envelope.schema.json)
 
-The envelope schema defines the union types for requests, responses, and events. Consult the file directly for up-to-date structure and requirements.
+The envelope schema defines the union types for requests, responses, and events. Consult the file directly for
+up-to-date structure and requirements.
 
 ### Method Schemas
 
 All method schemas are maintained in the [SCHEMA/1.0/methods/](SCHEMA/1.0/methods/) directory.  
 For example:
+
 - [session.hello.request.json](SCHEMA/1.0/methods/session.hello.request.json)
 - [session.welcome.response.json](SCHEMA/1.0/methods/session.welcome.response.json)
 
 Refer to these files for current field requirements and formats.
 
 ### Common Schemas
 
-Reusable schema definitions (such as `tool`, `capabilities`, and `error`) are in [SCHEMA/1.0/common/](SCHEMA/1.0/common/).  
+Reusable schema definitions (such as `tool`, `capabilities`, and `error`) are in
+[SCHEMA/1.0/common/](SCHEMA/1.0/common/).
 See:
+
 - [tool.schema.json](SCHEMA/1.0/common/tool.schema.json)
 - [error.schema.json](SCHEMA/1.0/common/error.schema.json)
 - [capabilities.schema.json](SCHEMA/1.0/common/capabilities.schema.json)
@@ -140,12 +147,14 @@ Event message schemas are in [SCHEMA/1.0/events/](SCHEMA/1.0/events/).
 
 ## AsyncAPI Implementation (Optional)
 
-If AsyncAPI documentation is provided, refer to the canonical file (e.g. `asyncapi.yaml`) at the root or docs directory for the latest event channel definitions.
+If AsyncAPI documentation is provided, refer to the canonical file (e.g. `asyncapi.yaml`) at the root or docs directory
+for the latest event channel definitions.
 
 ## Transport and Security Specifications
 
 See [SPEC/1.0/transport.md](SPEC/1.0/transport.md) for details.  
-Platform-specific bridge configuration examples are kept in the documentation and config files—refer to those for current formats.
+Platform-specific bridge configuration examples are kept in the documentation and config files—refer to those for
+current formats.
 
 ## Versioning Policy
 
@@ -159,8 +168,10 @@ Always refer to the workflow file for current validation logic.
 ## Conformance Test Suite
 
 Valid and invalid examples are maintained in:
+
 - [EXAMPLES/1.0/](EXAMPLES/1.0/) for protocol message examples
-- [CONFORMANCE/1.0/valid/](CONFORMANCE/1.0/valid/) and [CONFORMANCE/1.0/invalid/](CONFORMANCE/1.0/invalid/) for conformance testing
+- [CONFORMANCE/1.0/valid/](CONFORMANCE/1.0/valid/) and [CONFORMANCE/1.0/invalid/](CONFORMANCE/1.0/invalid/) for
+  conformance testing
 
 Consult these folders for up-to-date cases.
 
@@ -175,7 +186,7 @@ See [packages/js/gabp-schemas/README.md](packages/js/gabp-schemas/README.md) for
 ## Release Process Checklist
 
 1. **Freeze** SPEC/1.0 content
-2. **Tag** repository with `v1.0.0`
+2. **Tag** repository with `vX.Y.Z`
 3. **Create** GitHub Release bundling `/SCHEMA/1.0` and `/EXAMPLES/1.0`
 4. **Announce** registry and contribution rules
 

CHANGELOG.md

@@ -1,48 +1,70 @@
 # Changelog
 
+<!-- markdownlint-disable MD024 -->
+
 All notable changes to the GABP specification and schemas will be documented in this file.
 
-The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to
+[Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
 ## Unreleased
 
+## 1.1.0 - 2026-03-21
+
 ### Added
-- Added an architecture note for additive attention and execution gating support within `gabp/1`, including rationale, compatibility decisions, and an ordered build-and-test plan across GABP, Lib.GAB, GABS, and game integrations.
-- Added canonical additive attention protocol surface documentation for `attention/current`, `attention/ack`, and the `attention/opened`, `attention/updated`, and `attention/cleared` lifecycle channels.
+
+- Added an architecture note for additive attention and execution gating support within `gabp/1`, including rationale,
+  compatibility decisions, and an ordered build-and-test plan across GABP, Lib.GAB, GABS, and game integrations.
+- Added canonical additive attention protocol surface documentation for `attention/current`, `attention/ack`, and the
+  `attention/opened`, `attention/updated`, and `attention/cleared` lifecycle channels.
 - Added reusable attention schemas, attention examples, and valid/invalid conformance fixtures.
+- Added GitHub Actions automation to create and publish subdirectory-prefixed Go schema module tags.
 
 ### Changed
+
 - Updated the canonical JS and Go schema package mirrors to include the new attention assets.
 - Extended the AsyncAPI event documentation and AI implementer guide to cover optional attention-aware flows.
+- Updated the npm and NuGet publish workflows to ignore subdirectory-prefixed release tags intended for the Go schema
+  module.
+- Enforced repository-wide markdown validation in CI now that the documentation set is lint-clean.
+- Refreshed the schema package READMEs and Go module release guidance.
 
 ## 1.0.3 - 2026-03-15
 
 ### Fixed
-- Removed the custom `dotnet pack --output` path from the NuGet workflow and now publish from the default package output directory.
+
+- Removed the custom `dotnet pack --output` path from the NuGet workflow and now publish from the default package output
+  directory.
 
 ## 1.0.2 - 2026-03-15
 
 ### Fixed
+
 - Restored the repository metadata required for npm trusted publishing provenance.
 - Fixed the GitHub Actions `.NET` pack steps for the `Gabp.Schemas` package.
 
 ## 1.0.1 - 2026-03-15
 
 ### Added
+
 - Added the `wire-model-decisions.md` note to pin the canonical 1.0 field and naming choices.
-- Added explicit `tools/call` request and response examples plus valid and invalid conformance cases for tool naming and tool descriptors.
+- Added explicit `tools/call` request and response examples plus valid and invalid conformance cases for tool naming and
+  tool descriptors.
 - Added a new `.NET` schema package scaffold for `Gabp.Schemas`.
 - Added a new `Go` schema package scaffold with embedded schema assets and a sync script.
 - Added GitHub Actions automation to verify and publish the NuGet package.
 
 ### Changed
-- Aligned the 1.0 schemas, examples, and conformance assets around `arguments`, `capabilities.methods`, and slash-style native tool names.
+
+- Aligned the 1.0 schemas, examples, and conformance assets around `arguments`, `capabilities.methods`, and slash-style
+  native tool names.
 - Updated the bundled JS schema package assets and package metadata to match the canonical schema tree.
 - Removed avoidable `Pardeike` branding from package and documentation surfaces inside `GABP`.
 
 ## 1.0.0 - 2026-03-15
 
 ### Added
+
 - First stable release of GABP specification
 - Wire protocol version `gabp/1`
 - Complete JSON Schema definitions

CODE_OF_CONDUCT.md

@@ -2,7 +2,10 @@
 
 ## Our Pledge
 
-We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
+We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for
+everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity
+and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion,
+or sexual identity and orientation.
 
 We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
 
@@ -26,24 +29,33 @@ Examples of unacceptable behavior include:
 
 ## Enforcement Responsibilities
 
-Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
+Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take
+appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
 
-Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
+Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits,
+issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for
+moderation decisions when appropriate.
 
 ## Scope
 
-This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
+This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing
+the community in public spaces. Examples of representing our community include using an official e-mail address, posting
+via an official social media account, or acting as an appointed representative at an online or offline event.
 
 ## Enforcement
 
-Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at [INSERT CONTACT METHOD]. All complaints will be reviewed and investigated promptly and fairly.
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible
+for enforcement at [INSERT CONTACT METHOD]. All complaints will be reviewed and investigated promptly and fairly.
 
 All community leaders are obligated to respect the privacy and security of the reporter of any incident.
 
 ## Attribution
 
-This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.0, available at https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.0, available at
+<https://www.contributor-covenant.org/version/2/0/code_of_conduct.html>.
 
-Community Impact Guidelines were inspired by [Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity).
+Community Impact Guidelines were inspired by
+[Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity).
 
-[homepage]: https://www.contributor-covenant.org
+[homepage]: https://www.contributor-covenant.org

CONFORMANCE/1.0/README.md

@@ -1,6 +1,7 @@
 # GABP 1.0 Conformance Tests
 
-This directory contains conformance test cases for validating GABP implementations. These tests ensure that implementations correctly handle valid and invalid messages.
+This directory contains conformance test cases for validating GABP implementations. These tests ensure that
+implementations correctly handle valid and invalid messages.
 
 ## Test Categories
 
@@ -12,23 +13,27 @@ This directory contains conformance test cases for validating GABP implementatio
 Conformance tests serve multiple purposes:
 
 ### For Implementers
+
 - Verify your implementation handles edge cases correctly
 - Test error handling for malformed messages
 - Ensure compatibility with the GABP specification
 
 ### For Protocol Development
+
 - Validate schema definitions catch expected errors
 - Document expected behavior for corner cases
 - Regression testing during protocol evolution
 
 ### For Continuous Integration
+
 - Automated validation that examples conform to schemas
 - Prevent accidental breaking changes to schemas
 - Ensure consistency between specification and implementation
 
 ## Running Conformance Tests
 
 ### Valid Messages
+
 All messages in `valid/` should validate against their respective schemas:
 
 ```bash
@@ -39,7 +44,8 @@ ajv -s ../../SCHEMA/1.0/envelope.schema.json -d 'valid/*.json'
 ajv -s ../../SCHEMA/1.0/methods/session.hello.request.json -d 'valid/session-hello-*.json'
 ```
 
-### Invalid Messages  
+### Invalid Messages
+
 All messages in `invalid/` should fail validation:
 
 ```bash
@@ -52,13 +58,15 @@ The `--invalid` flag tells AJV that validation failures are expected.
 ## Test Organization
 
 Test files are named to indicate what they test:
+
 - `valid-session-hello-basic.json` - Basic valid session/hello message
 - `invalid-missing-version.json` - Message missing required version field
 - `invalid-wrong-type.json` - Message with invalid type field
 
 ## CI Integration
 
 These tests run automatically in GitHub Actions to ensure:
+
 - All valid messages pass schema validation
 - All invalid messages fail schema validation as expected
 - Schema changes don't break existing valid messages
@@ -67,7 +75,8 @@ These tests run automatically in GitHub Actions to ensure:
 ## Adding New Tests
 
 When adding conformance tests:
+
 1. Include both positive and negative test cases
-2. Test edge cases and boundary conditions  
+2. Test edge cases and boundary conditions
 3. Document what each test validates in comments
-4. Follow the naming convention for discoverability
+4. Follow the naming convention for discoverability

CONFORMANCE/1.0/invalid/README.md

@@ -1,21 +1,25 @@
 # Invalid Conformance Test Cases
 
-This directory contains GABP messages that should fail validation against the schemas. These represent malformed, incorrect, or prohibited messages that implementations must reject.
+This directory contains GABP messages that should fail validation against the schemas. These represent malformed,
+incorrect, or prohibited messages that implementations must reject.
 
 ## Test Categories
 
 ### Schema Violations
+
 - **Missing required fields** - Messages lacking mandatory properties
 - **Wrong field types** - Fields with incorrect data types
 - **Invalid field values** - Values outside allowed ranges or patterns
 - **Extra fields** - Additional properties where not allowed
 
-### Protocol Violations  
+### Protocol Violations
+
 - **Conflicting fields** - Messages with mutually exclusive properties
 - **Invalid combinations** - Field combinations that violate protocol rules
 - **Wrong message structure** - Incorrect envelope format
 
 ### Common Error Cases
+
 - **Missing version** - Messages without the required `v` field
 - **Wrong version** - Messages with invalid version strings
 - **Missing ID** - Messages without unique identifiers
@@ -26,6 +30,7 @@ This directory contains GABP messages that should fail validation against the sc
 ## Expected Behavior
 
 When implementations encounter these messages they should:
+
 - **Reject** the message during parsing or validation
 - **Return an error** (if it's a request message)
 - **Log the issue** appropriately
@@ -45,6 +50,7 @@ The `--invalid` flag tells AJV that validation failures are expected and desired
 ## File Naming
 
 Invalid test files describe what's wrong:
+
 - `invalid-missing-version.json` - Missing required version field
 - `invalid-wrong-type.json` - Incorrect message type
 - `invalid-both-result-error.json` - Response with both result and error
@@ -53,16 +59,18 @@ Invalid test files describe what's wrong:
 ## Error Documentation
 
 Each test case should document:
+
 - What makes the message invalid
 - What error should be reported
 - Which schema rule is being violated
 
 ## Implementation Testing
 
 Use these tests to verify your implementation:
+
 1. **Parsing robustness** - Handles malformed JSON gracefully
 2. **Validation accuracy** - Catches all schema violations
 3. **Error reporting** - Provides clear, actionable error messages
 4. **Security** - Doesn't crash or leak information on bad input
 
-These tests help ensure your GABP implementation is robust and secure when handling incorrect or malicious input.
+These tests help ensure your GABP implementation is robust and secure when handling incorrect or malicious input.