Skip to content

Make the lint targets resolve their own tooling - #795

Draft
shreyav wants to merge 1 commit into
mainfrom
claude/fix-make-lint
Draft

Make the lint targets resolve their own tooling#795
shreyav wants to merge 1 commit into
mainfrom
claude/fix-make-lint

Conversation

@shreyav

@shreyav shreyav commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Summary

Two unrelated faults in the lint plumbing. Makefile + package.json, 4 lines.

1. make lint-markdown never worked

The target runs npm run lint:markdown, and that script doesn't exist — so it failed with npm's "Missing script" error rather than any lint output.

markdownlint-cli is already a devDependency and .markdownlint.json is already committed, so the script was the only missing piece. Added:

"lint:markdown": "markdownlint \"mintlify/**/*.mdx\""

The target now fails with real lint output instead of a missing-script error — roughly 450 violations across mintlify/**/*.mdx, dominated by MD031 (79), MD012 (77), MD022 (74) and MD009 (74). Almost all are whitespace.

That is the intended outcome here: a linter reporting genuine violations is working, and the previous state hid them entirely. Fixing the 450 is deliberately not in this PR — it's a large mechanical reformat that would conflict with every open docs PR, including #794, which adds 927 lines to external-accounts.mdx. It should land on its own once the docs queue is clear.

2. npx spectral can execute a package nobody vetted

lint:openapi and the lint-spectral target both called npx spectral. That resolves correctly once dependencies are installed@stoplight/spectral-cli provides a spectral bin.

On a clean checkout it does not. npx finds no local binary, falls through to the registry, and silently downloads and runs an unrelated package that happens to be named spectral. The lint then appears to pass, having executed something that isn't Spectral at all.

Calling the binary directly from an npm script uses node_modules/.bin and cannot fall through:

- npx spectral lint openapi.yaml --fail-severity=error
+ spectral lint openapi.yaml --fail-severity=error

Also adds a lint:spectral script so the Makefile target routes through npm rather than reaching for npx itself.

Correcting something I've been repeating

I have described make lint as "broken on main" in several recent PR descriptions (#661, #777, #793, #794), attributing it to spectral resolving to a stub. That was overstated. make lint works fine on a checkout with dependencies installed — I hit the failure in an environment where npm install hadn't been run and generalised from it. The stub-resolution hazard is real and worth removing, but it is a fresh-checkout footgun, not a permanently broken target. The genuinely broken one was always lint-markdown.

Verification

  • make lint-spectral → exit 0, and node_modules/.bin/spectral confirmed to symlink @stoplight/spectral-cli/dist/index.js
  • make lint-markdown → now executes the linter and reports violations (exit 1) instead of "Missing script"
  • No lockfile churn — package-lock.json untouched
  • Script ordering in package.json kept readable; no other scripts altered

Generated by Claude Code

Two separate faults in the lint plumbing.

make lint-markdown ran npm run lint:markdown, and no such script
existed, so the target had never worked - it failed with "Missing
script" rather than any lint output. markdownlint-cli is already a
devDependency and .markdownlint.json is already committed, so the
script was the only missing piece. It now runs, and it reports real
violations: roughly 450 across mintlify/**/*.mdx, mostly MD031, MD012,
MD022 and MD009. Those want a separate mechanical pass, and one should
not land while large doc PRs are open - the point here is that the
target does its job instead of erroring.

lint:openapi and lint-spectral invoked "npx spectral". That works once
dependencies are installed, but on a clean checkout npx finds no local
spectral binary and silently downloads an unrelated registry package of
that name, then runs it. The lint appears to pass having executed
something nobody vetted. Calling the binary directly from an npm script
uses node_modules/.bin and cannot fall through to the registry.

Adds lint:spectral so the Makefile target routes through npm rather
than reaching for npx itself.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MMnjJ8yWJsui7jLqqrDrL4
@vercel

vercel Bot commented Aug 4, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments
Project Deployment Actions Updated (UTC)
grid-flow-builder Ignored Ignored Aug 4, 2026 3:54pm
grid-wallet-demo Ignored Ignored Aug 4, 2026 3:54pm

Request Review

kphurley7 added a commit that referenced this pull request Aug 13, 2026
…led (#799)

## Reason

`PATCH /cards/{id}` documented a `202` -> signed-retry flow that the
implementation never had: it returns `200` directly, authenticated by
the platform credential. One of the two has to give.

The spec should give, because the documented flow is wrong for this
verb. The 202 pattern signs the challenge with the session private key
of a verified authentication credential **on the card's owning internal
account** - the end user's key. That models actions taken *by* a user on
their own credentials or funds, which is why `DELETE
/auth/credentials/{id}` and `POST /internal-accounts/{id}/export` use
it.

Freezing or closing a card is routinely an action taken *about* a user
and without them present: fraud response, offboarding, an ops-driven
freeze. Under the documented flow none of those are possible through the
public API, and the cardholder may be the adversary. We would have had
to add a platform-authenticated bypass almost immediately, and that
bypass would have become the path everyone actually used.

## Overview

- Drops the 202 -> signed-retry prose and replaces it with why this
endpoint is platform-authenticated.
- Drops the `Grid-Wallet-Signature` and `Request-Id` header parameters.
- Drops the `202` response.
- `200` is no longer described as "signed retry accepted".
- Rewrites the `401` description, which described signature and
challenge failures.

Sensitive-data operations stay SCA-railed: `POST /cards/{id}/reveal` and
3DS password retrieval are unchanged, because there the cardholder is
the party being served and user-present signing is the right model.

## Notes

No implementation change accompanies this - sparkcore already behaves
this way, so this closes the divergence rather than opening one. Nothing
is affected downstream: the card program is gated behind
`GRID_CARD_PROGRAM_ENABLED` and is not public.

Redocly validates clean; warning count unchanged at 50, none in this
file. Spectral does not run locally (see #795).

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants