Skip to content

Replace vendored crates/sc-lint-boundary with upstream sc-lint-boundary #1588

Description

@randlee

Rand, 2026-09-23: "we should be using sc-lint-boundary" (upstream), not the in-tree copy.

State today:

  • just lint runs the vendored crates/sc-lint-boundary via cargo run; it is the only parser that accepts our boundaries/**/*.toml.
  • Released sc-lint 0.4.0 / 0.5.0 reject public.trait (54 files). sc-lint develop (e2477c38857537c8bcd34cf3873ee9726ef8d12a, 0.6.0 unreleased) accepts trait but rejects no_in_repo_implementation (boundaries/atm-core/atm-protocol.toml:39); further unknown fields may follow.
  • Found because the sc-publish kit's Release Preflight ran sc-lint lint sc-boundary as a gate (sc-publish#67 regression, removed by sc-publish#115). Publication no longer depends on this.

Work: diff the vendored crate against upstream sc-lint-boundary, upstream the inventory fields we rely on (or drop them), get an sc-lint release that parses our inventory, switch .just/lint_sc_boundary.py to the released binary, delete crates/sc-lint-boundary (and crates/sc-lint-directives if it is the same story). Post-1.6.1.

🤖 Generated with Claude Code

Activity

  1. github-actions commented on Sep 24, 2026

    @github-actions

    🤖 Hi @randlee, I've received your request, and I'm working on it now! You can track my progress in the logs for more details.

  2. github-actions commented on Sep 24, 2026

    @github-actions

    🤖 I'm sorry @randlee, but I was unable to process your request. Please see the logs for more details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions