docs: narrow tool-profile allowlist claim; document column-visibility fix

Task 12 (documentation-accuracy pass, no logic changes):

- CLAUDE.md's "Keeping tool categories in sync" section overclaimed that
  LEGACY_CATEGORIES_DEFAULT_ON keeps a custom profile from silently
  widening to include "a tool" it never opted into. The allowlist is
  category-granular, not tool-name-granular: a new tool joining an
  already-legacy category (e.g. a future addition to record-write) still
  resolves an absent customTools key to enabled for standalone npm/CLI
  users. tool-config.js's ponytail comment and both CHANGELOGs already
  scoped this correctly (from eb87f60); CLAUDE.md was the one site that
  still overclaimed. Narrowed to name the residual gap, who's affected,
  and the remedy.

- Added the missing release note for 455bfda's column-visibility predicate
  unification: an absent `visibility` key on a source column previously
  compared as hidden in sync/apply.js and sync/remap.js, matching an
  explicitly-hidden dest column and reporting false convergence — masking
  real drift. Documented in both CHANGELOGs as a correctness fix (not a
  regression): a base pair previously reported converged/identical by
  `sync_base mode=diff` may now correctly surface column-visibility drift.

- Investigated whether any CHANGELOG/comment records autoNumber as a
  confirmed current bug in sync/apply.js (per owner: create and
  primary-retype already strip maxUsedAutoNumber, and the diff engine
  doesn't emit the suspected failing update). Found no such record in the
  tracked tree — the only matching claim lives on an external PR review
  thread, handled separately. No edit made.

Zero executable-code changes: CHANGELOG.md, CLAUDE.md, and
packages/mcp-server/CHANGELOG.md only.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: ARHAEEM

CHANGELOG.md

@@ -66,6 +66,22 @@ already shipped.
   documentation gap ahead of merge.
 
 #### Fixed
+- **`sync_base`'s column-visibility comparison no longer produces a false
+  negative.** Airtable's internal API omits the `visibility` key entirely for
+  a visible column in some responses (absent = visible, explicit `false` =
+  hidden); the sync engine's `apply`/`diff` column-visibility handling
+  (`sync/apply.js`, `sync/remap.js`) previously treated an absent key as
+  *hidden* instead, the opposite of `getView`'s own long-standing semantics.
+  A source column returned without the key therefore compared as hidden
+  against a dest column explicitly `false`, which **matched** — masking real
+  column-visibility drift behind a false `converged`/`identical` verdict —
+  and `apply` never re-showed that column on the destination. The predicate
+  is now unified behind one function (`src/column-visibility.js`) shared by
+  `client.js` and both sync sites. **This is a correctness fix, not a
+  regression:** the drift was always real, just hidden by the comparison
+  bug. A base pair that previously reported `sync_base mode=diff` as
+  `converged`/`identical` may now correctly surface column-visibility drift
+  on the next run — re-run `mode=apply` to converge it.
 - **The daemon's orphan-process sweep (Stop button / `stopDaemon` command) no
   longer kills unrelated Node processes on a loose command-line match.** The
   previous kill criteria were an unanchored substring match against

CLAUDE.md

@@ -272,7 +272,9 @@ The **authoritative** tool → category mapping lives in `packages/mcp-server/sr
 
 Run `pnpm check:tool-sync` — must print green ✓ before committing. It also runs as part of `pnpm build` and `pnpm test`.
 
-A newly added category defaults to **off** for pre-existing `custom`-profile users by design: `ToolConfigManager.enabledToolNames()` in `tool-config.js` resolves a tool with no key in an on-disk `customTools` map to enabled only if its category is in the frozen `LEGACY_CATEGORIES_DEFAULT_ON` allowlist. Do not add the new category to that allowlist — leaving it out is what keeps a `custom` profile from silently widening to include a tool it never explicitly opted into.
+A newly added *category* defaults to **off** for pre-existing `custom`-profile users by design: `ToolConfigManager.enabledToolNames()` in `tool-config.js` resolves a tool with no key in an on-disk `customTools` map to enabled only if its category is in the frozen `LEGACY_CATEGORIES_DEFAULT_ON` allowlist. Do not add the new category to that allowlist — leaving it out is what keeps a `custom` profile from silently widening to include a *new category's* tools it never explicitly opted into.
+
+This guards categories only, not individual tools — it is not a fully-solved invariant. A new tool added to an *already-legacy* category (one already on the allowlist, e.g. a future addition to `record-write`) still resolves an absent `customTools` key to enabled, indistinguishable from a tool that predates the config. This affects **standalone `airtable-user-mcp` npm/CLI users only**: the VS Code extension's `syncSettingsToFile()` (`tool-profile.ts`) always writes an explicit key for all 71 tools, so the absent-key path never applies to it. Tracked as known standalone-server hardening (see the `ponytail:` comment on `LEGACY_CATEGORIES_DEFAULT_ON` in `tool-config.js` and `packages/mcp-server/CHANGELOG.md`'s "Known limitations" entry); remedy is re-running `manage_tools` (`toggle_tool`/`toggle_category`) or hand-editing `~/.airtable-user-mcp/tools-config.json` with an explicit key for the new tool. The real fix — a frozen tool-**name** allowlist alongside/instead of the category allowlist — is a deliberate scope cut, not yet done.
 
 <!-- PERPLEXITY-MCP-START -->
 # Perplexity MCP Server

packages/mcp-server/CHANGELOG.md

@@ -92,6 +92,30 @@
 - **`AIRTABLE_HTTP_CLIENT=impit` ignores the proxy environment.** impit takes an explicit `proxyUrl` and has no `NO_PROXY` support, so a partial implementation would be misleading. **Workaround:** use the default `fetch` client behind a proxy.
 - **`ALL_PROXY` is not honoured** (undici's env contract does not include it). Setting it alone logs a warning pointing at `HTTPS_PROXY`.
 
+### Fixed (2026-07-25 sync column-visibility)
+
+- **`sync_base mode=diff`/`mode=apply` — column-visibility comparison no
+  longer produces a false negative on an absent `visibility` key.**
+  Airtable's internal API omits the `visibility` key entirely for a visible
+  column in some responses (absent key = visible; visibility is only ever
+  explicitly `false` for a hidden column) — `client.js`'s `getView` has
+  always honoured this correctly, but `sync/remap.js`'s
+  `canonicalizeViewConfig` (feeds `mode=diff`'s classified compare) and
+  `sync/apply.js`'s `applyViewConfig` columns facet both treated an absent
+  key as **hidden**, backwards from `getView`'s semantics. A source column
+  returned without the key therefore canonicalized as hidden, which
+  **matched** a dest column explicitly `false` and reported convergence —
+  silently masking real column-visibility drift — and `apply` never
+  re-showed that column on the destination. All four read sites
+  (`client.js`'s `getView` + `_showColumnsWithRetry`, `sync/apply.js`,
+  `sync/remap.js`) now share one predicate, `isColumnVisible()` in the new
+  `src/column-visibility.js`, so the semantics cannot re-diverge.
+  **This is a correctness fix that surfaces previously-hidden drift, not a
+  regression:** a base pair previously reported `converged` or `identical`
+  by `mode=diff` may correctly report column-visibility drift on the next
+  run for any column whose source `columnOrder` entry omits `visibility`;
+  re-run `mode=apply` to converge it.
+
 ### Fixed (2026-07-09 field-ref & upload bug report)
 
 - **`download_base_formulas` / `download_formula_field` now emit real field names.** Airtable's internal API stores formulas with opaque `{column_value_fldXXX}` refs; downloads previously wrote them verbatim, producing unreadable files that Airtable rejected on re-upload ("Unknown field names: column_value_…"). Field refs are now resolved to `{Field Name}` (Airtable's native syntax) via a base-wide id→name map (`src/formula-refs.js`); an unknown id — or a name that cannot round-trip (contains braces, or is itself shaped like a ref token, e.g. a field literally named `fldXXX…`) — falls back to the `{fldXXX}` id form, which the write API accepts. Non-field placeholder tokens (e.g. n8n's `{ACCOUNT_TITLE_PLACEHOLDER}`) never match the fld-id pattern and pass through verbatim.