release: prepare v10.0.3 - #193
Conversation
Why: Canonical documentation and repository maintenance required a deterministic managed surface with two documentation recipes and no legacy Python or shell implementations. Breaking: Removes per-document scripts, persistent docs customization, shell release helpers, and nested repository-skill tests. Verification: just docs-check just repo-sync just test git diff --check
Why: Socket now uses one essential integration validation path and one root end-to-end test, with no nested or unit suites. Breaking: Permanently removes the swiftasb-skills plugin, its marketplace surfaces, tests, and repository references. Verification: just docs-check just repo-validate just test git diff --check
Why:\nSocket now uses managed FSX assets and root Just entrypoints without a second Python or shell maintenance stack.\n\nBreaking:\nRemoves SwiftASB, Python bootstrap/project/FastAPI/FastMCP skills, customization files, nested tests and evals, ACCESSIBILITY.md, and legacy automation commands.\n\nVerification:\njust docs-check\njust repo-validate\njust test\ngit diff --check
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b72ea542be
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| elif dryRun then | ||
| printfn "%s" (JsonSerializer.Serialize({| status = "success"; operation = operation; workspace_root = repo; dry_run = true; policy = "fixed-gale-workspace" |}, JsonSerializerOptions(WriteIndented = true))) | ||
| else | ||
| if operation = "create" || operation = "align" || operation = "adopt" then ensureCanonicalRoot () |
There was a problem hiding this comment.
Preserve repositories during align and adoption
When --operation align or --operation adopt --apply is run on an existing repository, this unconditional call rewrites project.yml, all three shared registries, AGENTS.md, CONTRIBUTING.md, and justfile in place. It also ignores the documented --adoption-map candidate workflow, so adoption can destroy existing project and documentation state rather than producing the separate reviewable candidate promised by the skill; align likewise fails to preserve content outside managed markers.
AGENTS.md reference: AGENTS.md:L43-L44
Useful? React with 👍 / 👎.
| | "app" | "extension" -> | ||
| let target = Path.Combine("Apps", componentName) | ||
| Directory.CreateDirectory(Path.Combine(repo, target, "Sources")) |> ignore | ||
| let platform = value "--platform" |> Option.defaultValue "iOS" | ||
| write (Path.Combine(target, "target.yml")) $"targets:\n {componentName}:\n type: application\n platform: {platform}\n sources: [Sources]\n" |
There was a problem hiding this comment.
Generate an extension target instead of an application
When --component-kind extension is selected, this branch always emits type: application and ignores --host-target, --extension-product-type, and --extension-point-identifier. The resulting target is an app rather than an extension and is never embedded in its host, so the documented extension workflow produces an invalid project graph.
AGENTS.md reference: AGENTS.md:L43-L44
Useful? React with 👍 / 👎.
| elif dryRun then | ||
| printfn "%s" (JsonSerializer.Serialize({| status = "success"; operation = operation; workspace_root = repo; dry_run = true; policy = "fixed-gale-workspace" |}, JsonSerializerOptions(WriteIndented = true))) | ||
| else | ||
| if operation = "create" || operation = "align" || operation = "adopt" then ensureCanonicalRoot () |
There was a problem hiding this comment.
Materialize the default workspace components on create
For the documented default invocation run-workflow.fsx --name <Name> --file-prefix <ABC>, the create path only calls ensureCanonicalRoot; it never creates the iOS/macOS app targets, test bundles, <Name>Core package, generated .xcodeproj, or repository-maintenance installation promised by the skill. A successful result therefore leaves an effectively empty workspace whose XcodeGen includes contain no targets.
AGENTS.md reference: AGENTS.md:L43-L44
Useful? React with 👍 / 👎.
| match kind with | ||
| | "library" | "service" -> | ||
| let rootName = if kind = "library" then "Packages" else "Services" | ||
| let target = Path.Combine(rootName, componentName) | ||
| Directory.CreateDirectory(Path.Combine(repo, target, "Sources", componentName)) |> ignore | ||
| write (Path.Combine(target, "Package.swift")) $"// swift-tools-version: 6.2\nimport PackageDescription\nlet package = Package(name: \"{componentName}\", platforms: [.macOS(.v15)], products: [.library(name: \"{componentName}\", targets: [\"{componentName}\"])], targets: [.target(name: \"{componentName}\")])\n" |
There was a problem hiding this comment.
Create an executable service through the selected framework
When --component-kind service is used, this shared branch emits the same library product and plain target as a library and never reads --framework. Consequently both --framework hummingbird and --framework vapor produce a non-executable empty package instead of delegating service generation to the documented server-side Swift adapter.
AGENTS.md reference: AGENTS.md:L43-L44
Useful? React with 👍 / 👎.
| copyManaged "AGENTS-packages.md" "Packages/AGENTS.md" | ||
| copyManaged "AGENTS-services.md" "Services/AGENTS.md" | ||
| copyManaged "CONTRIBUTING.md" "CONTRIBUTING.md" | ||
| copyManaged "pre-commit" ".git/hooks/pre-commit" |
There was a problem hiding this comment.
Install the pre-commit hook with executable permissions
On a newly created workspace, this copies the tracked pre-commit asset with mode 0644 and never marks the destination executable. Git ignores non-executable hooks on Unix/macOS, so the scaffold claims to install validation but commits proceed without running it.
Useful? React with 👍 / 👎.
| let issueCount = | ||
| report.Documents | ||
| |> List.sumBy (fun document -> document.Findings |> List.filter (fun finding -> finding.Severity = "error") |> List.length) | ||
| if not (List.isEmpty report.Errors) then 1 | ||
| elif failOnIssues && (issueCount > 0 || not (List.isEmpty responsibilityIssues)) then 2 |
There was a problem hiding this comment.
Fail documentation checks when canonical rendering differs
In check-only mode, a document with all required headings but noncanonical section order can produce a different canonical rendering without any audit error, yet this exit calculation considers only explicit findings and responsibility issues. just docs-check and repo-validate therefore return success even though a subsequent docs-apply rewrites the document, allowing managed documentation drift through CI.
AGENTS.md reference: AGENTS.md:L43-L44
Useful? React with 👍 / 👎.
Prepare v10.0.3 through the canonical repository-maintenance workflow.