release: socket 6.6.0

plugins/agent-plugin-skills/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-plugin-skills",
-  "version": "6.5.1",
+  "version": "6.6.0",
   "description": "Installable maintainer skills for skills-export repositories.",
   "author": {
     "name": "Gale",

plugins/agent-plugin-skills/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "agent-plugin-skills-maintenance"
-version = "6.5.1"
+version = "6.6.0"
 description = "Maintainer-only Python tooling baseline for agent-plugin-skills."
 requires-python = ">=3.11"
 dependencies = []

plugins/apple-dev-skills/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "apple-dev-skills",
-  "version": "6.5.1",
+  "version": "6.6.0",
   "description": "Apple development workflows for Codex and Claude Code, including SwiftUI architecture and DocC authoring guidance.",
   "author": {
     "name": "Gale",

plugins/apple-dev-skills/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "apple-dev-skills-maintainer"
-version = "6.5.1"
+version = "6.6.0"
 description = "Maintainer tooling for the apple-dev-skills repository"
 requires-python = ">=3.9"
 dependencies = []

plugins/cardhop-app/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "cardhop-app",
-  "version": "6.5.1",
+  "version": "6.6.0",
   "description": "Cardhop.app workflow guidance plus a bundled local MCP server for contact capture and updates on macOS.",
   "author": {
     "name": "Gale",

plugins/cardhop-app/mcp/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "cardhop-app-mcp"
-version = "6.5.1"
+version = "6.6.0"
 requires-python = ">=3.13"
 dependencies = [
     "fastmcp>=3.0.2",

plugins/dotnet-skills/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "dotnet-skills",
-  "version": "6.5.1",
+  "version": "6.6.0",
   "description": "Standalone plugin repository for future .NET-focused Codex skills.",
   "author": {
     "name": "Gale",

plugins/productivity-skills/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "productivity-skills",
-  "version": "6.5.1",
+  "version": "6.6.0",
   "description": "Broadly useful productivity workflows for Codex and Claude Code.",
   "author": {
     "name": "Gale",

plugins/productivity-skills/README.md

@@ -43,7 +43,7 @@ uv sync --dev
 Use this repository when the work is about:
 
 - explaining code paths in plain language
-- maintaining README, AGENTS, CONTRIBUTING, ACCESSIBILITY, or ROADMAP docs
+- maintaining README, AGENTS, CONTRIBUTING, ACCESSIBILITY, ARCHITECTURE, SLICES, or ROADMAP docs
 - keeping a general-purpose repository-maintenance baseline aligned
 - describing when Codex subagents are useful for bounded docs pulling, repo scans, triage, or summarization before the main workflow edits or reports
 - describing when OpenAI Codex Hooks belong in repo-local agent guidance or maintainer-tooling docs
@@ -85,6 +85,7 @@ See [LICENSE](./LICENSE).
 - `maintain-project-agents`
 - `maintain-project-accessibility`
 - `maintain-project-api`
+- `maintain-project-architecture`
 - `maintain-project-contributing`
 - `maintain-project-readme`
 - `maintain-project-repo`

plugins/productivity-skills/ROADMAP.md

@@ -165,6 +165,7 @@ Planned
 
 ## History
 
+- Added `maintain-project-architecture` as the baseline `docs/architecture/ARCHITECTURE.md`, `SLICES.md`, and `architecture.json` maintenance skill, with first-pass SwiftPM product/target detection and stale model checks.
 - Added first-pass OpenAI Codex Hooks guidance for AGENTS and repo-maintenance workflows, plus a planned `maintain-project-hooks` baseline skill for future deterministic hook audits.
 - Added maintainer guidance for optional Codex subagent use in documentation, maintenance, and explanation skills, keeping delegation explicitly user-triggered and read-heavy by default.
 - Fixed `maintain-project-repo` standard release handling so new release PRs wait for initial GitHub checks before watching CI, approval-only reviews no longer count as unresolved review comments, and release tags are created only after CI and the review-comment gate pass.

plugins/productivity-skills/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "productivity-skills-maintenance"
-version = "6.5.1"
+version = "6.6.0"
 description = "Maintainer-only Python tooling baseline for productivity-skills."
 requires-python = ">=3.11"
 dependencies = []
@@ -16,6 +16,7 @@ testpaths = [
   "skills/maintain-project-agents/tests",
   "skills/maintain-project-accessibility/tests",
   "skills/maintain-project-api/tests",
+  "skills/maintain-project-architecture/tests",
   "skills/maintain-project-readme/tests",
   "skills/maintain-project-contributing/tests",
   "skills/maintain-project-roadmap/tests",

plugins/productivity-skills/skills/explain-code-slice/SKILL.md

@@ -10,6 +10,7 @@ Use this skill when the user wants one bounded walkthrough of how part of a syst
 ## Purpose
 
 - Explain one slice end to end without dropping meaningful steps.
+- When the user wants the slice recorded durably, update `docs/architecture/SLICES.md` after the explanation.
 - Start with the incoming data shape, what it represents, who sends it, and why it enters the flow.
 - Walk the execution path in order, including boundaries, branch points, shared versus specialized steps, and data transformations.
 - End with the final output shape, who receives it, and what purpose it serves.
@@ -115,12 +116,31 @@ Return a structured narrative in this order:
 
 The writing should stay conversational and narrative-first. Avoid sterile dumps, but do not skip steps for brevity.
 
+## Persistent Slice Records
+
+Use this when the user asks to save, record, maintain, update, or add a slice to repository architecture docs.
+
+1. Explain the slice normally first.
+2. Ensure `docs/architecture/SLICES.md` exists. If it is missing, use the `maintain-project-architecture` structure: title, summary, slice index, and slices sections.
+3. Add or refresh one `## Slice: <Name>` section.
+4. Include:
+   - `### Trigger`
+   - `### Data Shapes`
+   - `### Step Trace`
+   - `### Boundaries`
+   - `### Outputs`
+   - `### Evidence`
+5. Every recorded step must include a file path and symbol when known. Include line numbers when available.
+6. Do not record a slice that cannot be proven from code. Say what evidence is missing instead.
+7. Do not use Mermaid or generic graph diagrams as the persistent slice format.
+
 ## Guardrails
 
 - Never silently collapse or omit meaningful steps in the requested slice.
 - Do not replace the end-to-end walkthrough with only a component map or only a high-level summary.
 - If the path is ambiguous, say where the ambiguity starts and explain the most likely path plus the alternate branch.
 - If a step cannot be proven from the code, say that plainly instead of guessing.
+- Do not persist unproven slice claims into `SLICES.md`.
 - Prefer concrete file/function references when available.
 - Keep branch and data-shape notes short and move clutter out of the main narrative when a marker note will do.
 

plugins/productivity-skills/skills/explain-code-slice/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Explain Code Slice"
   short_description: "Explain one code path or slice step by step."
-  default_prompt: "Use $explain-code-slice to explain or compare a code path from trigger to final output. Start with incoming data shape and purpose, then walk every meaningful step in order, including branches, boundaries, transformations, and a simple diagram with notes."
+  default_prompt: "Use $explain-code-slice to explain or compare a code path from trigger to final output. Start with incoming data shape and purpose, then walk every meaningful step in order, including branches, boundaries, transformations, and a compact step view with notes. When the user asks to save or record the slice, update docs/architecture/SLICES.md with a provable slice record instead of using generic diagrams."

plugins/productivity-skills/skills/maintain-project-architecture/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: maintain-project-architecture
+description: Maintain docs/architecture/ARCHITECTURE.md, SLICES.md, and architecture.json for a repository's product/module architecture and provable code slices. Use when a repo needs architecture docs that explain Swift products, modules, construction, ownership, evidence, stale claims, and slice inventory without generic diagrams or ungrounded architecture claims.
+---
+
+# Maintain Project Architecture
+
+Maintain the repo-local architecture documentation under `docs/architecture/`.
+
+This skill is related to `explain-code-slice`, but it owns the durable architecture files. `explain-code-slice` explains or records one end-to-end path. This skill keeps the repo-wide product/module map and the slice index coherent.
+
+## Inputs
+
+- Required: `--project-root <path>`
+- Required: `--run-mode <check-only|apply>`
+- Optional: `--architecture-dir <path>`
+
+## Workflow
+
+1. Resolve the project root and architecture directory.
+2. Detect Swift package products and targets when `Package.swift` exists:
+   - prefer `swift package dump-package` when it succeeds
+   - fall back to conservative `Package.swift` text scanning
+3. Build or refresh `docs/architecture/architecture.json` with product, target, evidence, and slice placeholders.
+4. In `check-only`, audit required files, required sections, and stale product or target facts in `architecture.json`.
+5. In `apply`, create missing architecture files and refresh generated model facts without inventing symbols, data flows, or ownership claims.
+6. Leave `SLICES.md` present even when no provable slices have been recorded yet.
+7. Re-run the same audit and report remaining findings.
+
+## Required Files
+
+- `docs/architecture/ARCHITECTURE.md`
+- `docs/architecture/SLICES.md`
+- `docs/architecture/architecture.json`
+
+## Writing Expectations
+
+- `ARCHITECTURE.md` is descriptive. Put preferences, constraints, and "do not" rules in `AGENTS.md`, not here.
+- Use fixed section names so Gale can ask for a specific section without ambiguity.
+- Treat Swift Package Manager products and targets as first-class architecture facts when available.
+- Explain products/modules in terms of what they do, who creates or consumes them, what they own, and what code evidence proves that claim.
+- Do not use Mermaid, generic graph diagrams, unlabeled arrows, curved-line diagrams, centered text, or diagram labels that interrupt connector lines.
+- Keep visual claims in structured `architecture.json` until a purpose-built viewer can render them with Gale-readable layout.
+- Every generated claim should have evidence: a file path, manifest entry, symbol, command output, or explicit "unverified" marker.
+
+## Visual Grammar
+
+Use `references/visual-grammar.md` when shaping any generated visual model or future viewer output.
+
+Core rules:
+
+- vertical flow dominates
+- left/top start position, never center-first reading
+- no center-aligned text
+- no unlabeled or ambiguous connectors
+- connectors must represent one explicit relationship kind such as `creates`, `passes`, `stores`, `calls`, `returns`, `owns`, or `depends-on`
+- data models appear before slice steps
+- code nodes must include symbol names and file anchors when known
+
+## Slices
+
+`SLICES.md` is always created. It may remain mostly empty until provable flows are discovered.
+
+When the user asks for a new slice explanation, use `explain-code-slice` for the walkthrough and update `docs/architecture/SLICES.md` with the slice if the path is provable from code.
+
+## Codex Subagent Fit
+
+When the user explicitly asks for subagents or parallel agent work, use subagents only for read-heavy discovery. Good jobs include scanning package manifests, listing products and targets, finding entrypoints, or tracing one candidate slice. Keep writes to `ARCHITECTURE.md`, `SLICES.md`, and `architecture.json` in the main thread so the architecture story stays coherent.
+
+## Output Contract
+
+- Return Markdown plus JSON with:
+  - `run_context`
+  - `detected_model`
+  - `schema_violations`
+  - `stale_claims`
+  - `fixes_applied`
+  - `post_fix_status`
+  - `errors`
+- If there are no issues and no errors, output exactly `No findings.`
+
+## Guardrails
+
+- Never auto-commit, auto-push, or open a PR.
+- Never invent products, modules, slices, symbols, data models, or code relationships.
+- Never edit files outside the architecture directory.
+- Never use generic architecture diagrams as filler.
+- Treat stale product or target facts as audit failures.
+
+## References
+
+- `assets/ARCHITECTURE.template.md`
+- `assets/SLICES.template.md`
+- `references/visual-grammar.md`
+- `references/architecture-json.md`
+- `scripts/maintain_project_architecture.py`

plugins/productivity-skills/skills/maintain-project-architecture/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Maintain Project Architecture"
+  short_description: "Maintain architecture docs and slice inventory from repo evidence."
+  default_prompt: "Use $maintain-project-architecture to create or refresh docs/architecture/ARCHITECTURE.md, SLICES.md, and architecture.json. Detect Swift products and targets from repo evidence, keep architecture descriptive rather than prescriptive, reject stale claims, avoid generic diagrams, and only record products, modules, symbols, data flows, or slices that are provable from code."

plugins/productivity-skills/skills/maintain-project-architecture/assets/ARCHITECTURE.template.md

@@ -0,0 +1,43 @@
+# Architecture
+
+## Summary
+
+This document explains the repository's product and module architecture from code evidence. Add repo-specific notes here when the layout has unusual constraints or naming.
+
+See [SLICES.md](./SLICES.md) for provable end-to-end code paths.
+
+## Product Map
+
+<!-- Generated product inventory starts here. -->
+
+No products have been recorded yet.
+
+<!-- Generated product inventory ends here. -->
+
+## Module Architecture
+
+<!-- Generated target inventory starts here. -->
+
+No modules have been recorded yet.
+
+<!-- Generated target inventory ends here. -->
+
+## Construction And Ownership
+
+Document who creates the important runtime objects, what inputs they receive, where those inputs come from, and which module owns the responsibility. Leave unverified relationships out until they can be proven from code.
+
+## Visual Model
+
+The structured visual model lives in [architecture.json](./architecture.json). It is intended for a purpose-built viewer rather than generic Markdown diagrams.
+
+## Architecture Evidence
+
+<!-- Generated evidence starts here. -->
+
+- No architecture evidence has been recorded yet.
+
+<!-- Generated evidence ends here. -->
+
+## Staleness Checks
+
+Refresh this document when products, targets, module boundaries, important construction paths, or recorded slices change.

plugins/productivity-skills/skills/maintain-project-architecture/assets/SLICES.template.md

@@ -0,0 +1,13 @@
+# Slices
+
+## Summary
+
+This file records provable end-to-end code slices for this repository. A slice should name the trigger, data shapes, code steps, boundaries, outputs, and evidence.
+
+## Slice Index
+
+No provable slices have been recorded yet.
+
+## Slices
+
+Add new slices here when they have code evidence.

plugins/productivity-skills/skills/maintain-project-architecture/references/architecture-json.md

@@ -0,0 +1,29 @@
+# Architecture JSON
+
+`architecture.json` is the structured source for future architecture viewers.
+
+## Top-level Shape
+
+```json
+{
+  "schemaVersion": 1,
+  "generatedBy": "maintain-project-architecture",
+  "projectRoot": "/path/to/repo",
+  "detectedAt": "2026-05-03T00:00:00Z",
+  "products": [],
+  "targets": [],
+  "relationships": [],
+  "slices": [],
+  "evidence": []
+}
+```
+
+## Records
+
+Product records include `name`, `kind`, `targets`, and `evidence`.
+
+Target records include `name`, `kind`, `dependencies`, `path`, and `evidence`.
+
+Relationship records include `kind`, `from`, `to`, `label`, and `evidence`.
+
+Do not create relationship records without evidence.