Version: 7.2.2

Framework Version: 11.10.0

Release Notes:

Concord2 7.2.2

Concord2 7.2.2 makes terminal paste dependable on Windows and macOS, including copied screenshots and Finder files.

What's improved

• Paste a copied screenshot or other supported image into the embedded terminal on Windows or macOS. Concord saves it under the project's git-ignored .concord/screenshots/ folder and inserts its quoted path at the prompt, ready for the agent to use.
• On macOS, Cmd+V now pastes text and Cmd+C copies the selected terminal text. Files copied in Finder are inserted as quoted paths, while copied screenshots are saved before their paths are inserted.
• If Studio Pro does not deliver Cmd+V on macOS, right-click the terminal with no text selected to paste.
• Windows text paste is unchanged: Ctrl+V continues to paste text as before.

Compatibility

• Windows x64 and macOS.
• Studio Pro 11.10 through 11.13. Studio Pro 10.x, including 10.22, is not supported.
• Studio Pro 11.13 on macOS requires Apple silicon; Intel macOS remains supported on earlier Studio Pro versions.
• Claude Code, Codex, GitHub Copilot CLI, and Grok Build.

Upgrade

1. Update Concord2 in place from Studio Pro's Marketplace panel, or import the downloaded .mxmodule over the existing Concord module.
2. Fully restart Studio Pro.
3. Open Concord2 and start a fresh agent terminal.

Version: 7.2.1

Framework Version: 11.10.0

Release Notes:

Concord2 - 7.2.1 restores one universal Marketplace package for Windows and Mac, strengthens project-local Copilot setup, and adds evidence-first guidance for customized Marketplace module upgrades.

What's improved

• One Windows-generated .mxmodule now contains Windows x64, macOS Apple-silicon, and legacy macOS Intel runtime payloads.

• Copilot now uses the effective project-root .mcp.json; Setup Status verifies the configuration Copilot actually reads and safely reconciles non-conflicting legacy .github/mcp.json entries.

• Marketplace module audit and guided-upgrade workflows can verify exact installed/target identity, stage hashed evidence outside the project, and check the result after Studio Pro's supported native replacement flow.

• Apple-silicon terminal resize, PTY teardown, GUI-launched PATH/locale recovery, Studio Pro MCP reconnect behavior, and settings persistence are more robust.

• The optional Maia HTTP MCP sidecar now requires a per-start token.

Compatibility

• Windows x64 and macOS.

• Studio Pro 11.10 through 11.13.

• Studio Pro 11.13 on macOS requires Apple silicon; the universal package retains an Intel runtime for earlier supported Studio Pro versions.

• Claude Code, Codex, GitHub Copilot CLI, and Grok Build.

Known limitation

Task delegation to Studio Pro's Maia does not work on macOS in this release. Use Concord and Studio Pro MCP for supported work, or complete the Maia step manually.

Upgrade

1. Import or update Concord2 from Marketplace.

2. Fully restart Studio Pro.

3. Open Concord2 once to refresh project-local agent configuration.

4. If an existing Copilot session still shows the old server list, run /mcp reload.

Version: 7.2.0

Framework Version: 11.10.0

Release Notes:

Concord2 7.2.0

This release makes in-Studio agent sessions more reliable, easier to verify, and less disruptive to the developer.

Highlights

• Reliable app control. Agents can sync, start, and restart the app through Studio Pro without taking over the mouse, keyboard, or focus. Restart results prove the app went down and came back ready.

• Safer upgrades. Concord now verifies the exact MCP runtime it loaded, repairs stale project configuration, and shows the loaded Host, MCP, and Core identity in Settings.

• A better terminal. CLI footer rows are visible from the first open, CLI color output is restored, and light-theme contrast is hardened.

• Smarter sessions. Quick Start opens a new tab when another agent is already active, and clearer context and approval-stall warnings help users recover sooner.

• Better Studio Pro workflow. Agents receive focused guidance for logs, editor cleanup, run/restart actions, project orientation, and honest completion evidence.

First-time setup for Studio Pro 11.12

1. In Studio Pro, open Edit > Preferences > AI > MCP Server.

2. Enable the MCP server, choose a port, and save the preference.

3. Install or update Concord2 and open Extensions > Concord > Open Concord2 Terminal once.

4. Fully restart Studio Pro before starting an agent CLI.

5. Reopen Concord2, run Setup Status, and start your CLI.

Compatibility

• Windows only; macOS payloads are not included.

• Studio Pro 11.10, 11.11, and 11.12.

• Claude Code, Codex, GitHub Copilot CLI, and Grok Build.

• Claude Code is the fully verified reference CLI. Codex and GitHub Copilot CLI have verified Concord MCP connections; Grok Build is project-wired, with deeper end-to-end workflow coverage still maturing.

Upgrade note

After importing this version, restart Studio Pro once before opening a new CLI session.

 

Version: 7.1.1

Framework Version: 11.10.0

Release Notes:

Version 7.1.1 — Concord2

Concord2 7.1.1 tightens the Windows Marketplace package, setup guidance, and in-pane reliability polish for Studio Pro 11.10, 11.11, and 11.12.

This release is about one thing: getting Studio Pro, Concord2, the Studio Pro MCP Server, and your CLI agent started in the right order so Concord can see the real project and report an honest setup state.

IMPORTANT: Studio Pro 11.12 setup order — restart before starting a CLI session.

01 - Open Studio Pro 11.12.

02 - Go to Edit > Preferences. Make any preference changes you want.

03 - Open AI > MCP Server. Enable the MCP server and select the port you want Studio Pro to use.

04 - Save and close Preferences.

05 - Download or import Concord2 from the Marketplace if you have not already done so.

06 - Open the terminal: Extensions > Concord > Open Concord2 Terminal.

07 - Click inside the terminal once so the pane can initialize and save its state.

08 - Fully restart Studio Pro.

09 - Reopen Concord2 Terminal and start your CLI session.

Why this matters: Studio Pro needs a full restart after this setup path so the extension and MCP preference state reload cleanly. If you skip the restart and start a CLI session immediately, Concord may not work correctly until Studio Pro is restarted.

What changed in 7.1.1

Windows-only Marketplace package. Starting with 7.1.1, the Marketplace module is Windows-only. Unsupported macOS MCP payloads are no longer included, which keeps the download lighter and makes the package match the supported platform statement.

Studio Pro 11.12 support. Concord now treats Studio Pro 11.12 as a first-class supported version alongside 11.10 and 11.11, with target-aware deploy, verification, and MCP freshness checks.

Studio Pro MCP preference resilience. If Concord detects that the Studio Pro 11.12 MCP preference entry is missing or incomplete, it backs up the settings database, writes the missing enable/port preference from the user's existing Studio Pro MCP configuration, and shows a clear restart notice. Concord stays aligned with Studio Pro's MCP configuration without guessing a port.

Setup notices that are harder to miss. Setup and restart guidance now appears as a stronger, sticky in-pane notice with better contrast, priority handling, and a real dismiss button, so lifecycle messages do not hide instructions that matter.

Cleaner Setup Checker. Because the 11.12 MCP preference repair now runs automatically when needed, the old manual repair row has been removed. Setup Checker stays focused on checks the user can still act on.

Compatibility

Supported platform: Windows. Supported Studio Pro versions: 11.10, 11.11, and 11.12. Supported agent CLIs: Claude Code, Codex, and GitHub Copilot. Starting with 7.1.1, the Marketplace module is Windows-only; macOS payloads are no longer included and macOS is not supported.

Upgrade note

After importing this version, restart Studio Pro before opening a CLI session in the Concord2 terminal.

Version: 7.1.0

Framework Version: 11.10.0

Release Notes:

Version 7.1.0 — Concord2

Concord2 7.1.0 adds Studio Pro 11.12 support and a cleaner first-open path for Studio Pro MCP Server setup.

This release is about one thing: getting Studio Pro, Concord2, the Studio Pro MCP Server, and your CLI agent started in the right order so Concord can see the real project and report an honest setup state.

IMPORTANT: Studio Pro 11.12 setup order — restart before starting a CLI session.

01 - Open Studio Pro 11.12.

02 - Go to Edit > Preferences. Make any preference changes you want.

03 - Open AI > MCP Server. Enable the MCP server and select the port you want Studio Pro to use.

04 - Save and close Preferences.

05 - Download or import Concord2 from the Marketplace if you have not already done so.

06 - Open the terminal: Extensions > Concord > Open Concord2 Terminal.

07 - Click inside the terminal once so the pane can initialize and save its state.

08 - Fully restart Studio Pro.

09 - Reopen Concord2 Terminal and start your CLI session.

Why this matters: Studio Pro needs a full restart after this setup path so the extension and MCP preference state reload cleanly. If you skip the restart and start a CLI session immediately, Concord may not work correctly until Studio Pro is restarted.

What changed in 7.1.0

Studio Pro 11.12 support. Concord now treats Studio Pro 11.12 as a first-class supported version alongside 11.10 and 11.11, with target-aware deploy, verification, and MCP freshness checks.

Studio Pro MCP preference resilience. If Concord detects that the Studio Pro 11.12 MCP preference entry is missing or incomplete, it backs up the settings database, writes the missing enable/port preference from the user's existing Studio Pro MCP configuration, and shows a clear restart notice. Concord stays aligned with Studio Pro's MCP configuration without guessing a port.

Setup notices that are harder to miss. Setup and restart guidance now appears as a stronger, sticky in-pane notice with better contrast, priority handling, and a real dismiss button, so lifecycle messages do not hide instructions that matter.

Cleaner Setup Checker. Because the 11.12 MCP preference repair now runs automatically when needed, the old manual repair row has been removed. Setup Checker stays focused on checks the user can still act on.

Compatibility

Supported platform: Windows. Supported Studio Pro versions: 11.10, 11.11, and 11.12. Supported agent CLIs: Claude Code, Codex, and GitHub Copilot. The universal module may run in some macOS environments, but macOS is not currently a supported platform for this Marketplace release.

Upgrade note

After importing this version, restart Studio Pro before opening a CLI session in the Concord2 terminal.

 

Version: 7.0.2

Framework Version: 11.10.0

Release Notes:

One module, every platform. Clean connections, every time.

New

• macOS support — a single universal module for Windows and macOS (Intel + Apple Silicon), Studio Pro 11.10–11.11. Previously the module was Windows-only, so on a Mac the agent had no Concord tools.
• Readiness cues — a “wait for the green dot” hint while Studio Pro’s MCP server is still starting, plus a one-time reconnect reminder if your agent connected before it was ready.

Improved

• Zero-touch, project-only setup — all three coding-agent CLIs (Claude, Codex, Copilot) are configured entirely inside your project; nothing is written to your home folder and no machine-wide settings are touched. Claude’s MCP servers are auto-approved, so they connect with no manual trust step.

Fixed

• Multiple Studio Pro instances now connect to the right project — each instance reaches its own project’s Mendix tools instead of occasionally the wrong one.
• Correct SP-MCP port — Concord uses exactly the MCP port you configured, so the status no longer shows a false “unreachable.”
• First-time CLI wiring on every platform, including a macOS permission fix so the bundled server launches cleanly.
• Smooth upgrades — a stale configuration repairs itself the next time you open the Concord pane.

 

Version: 6.2.1

Framework Version: 10.24.13

Release Notes:

Concord 6.2.0 — Concord Intelligence

The bridge now actively helps the agent stay un-stuck. Six new MCP tools the agent calls itself, a server-side friction-detection layer that hands the agent a structured "you tried this twice — try something different" hint, a self-repair skill that lets the agent propose a unified-diff patch to Concord itself when the bridge is at fault, and a Maia resilience trio (heartbeat auto-reconnect, pre-flight bridge-health probe, programmatic Maia-panel auto-reopen) that turns 30-60s wobbles into invisible self-recoveries. Plus a live status strip, a first-5-minutes onboarding banner, and a monthly digest that rolls up what hurt across a project's month.

This is the cycle where Concord stops being a passive transport and starts being a participant.

Zero breaking changes for upgrades from v6.1.x. Settings persisted from v6.1.x carry forward unchanged; two new optional fields (EnableFriction defaulted true, HiddenOnboardingBanner defaulted false) merge through the existing optional-default passthrough.

What's new

NEW Six new MCP orientation + verification tools

• • concord__session_context — one-call project briefing. Returns a 6-section orientation (identity, project, tooling, friction policy, listening posture, known limits) so the agent's first turn no longer has to play 20 questions.
  • concord__find_tool — semantic tool discovery. The agent describes what it's trying to do ("create a microflow that returns the active user") and gets the right tool name back with rationale. Replaces tool-name guessing.
  • concord__diagnose_project — 7 parallel health probes (entity graph, microflow refs, theme integrity, MCP wiring, Maia reachability, ports, settings hygiene) under a 4-second total budget. Tells the agent what's wrong before it burns calls on a broken slot.
  • concord__verify — recipe-driven post-action verification. The agent declares "I just created entity X" and verify runs the entity_created recipe and tells the agent whether the model actually contains it now.
  • concord__set_task_context — task-scoped tool catalog pruning. The agent declares its current task family ("editing-microflows") and the catalog hides irrelevant tools so the next tool-search ranks faster.
  • concord__silence_friction — per-tool false-positive opt-out for the friction layer. When the agent legitimately needs to retry a tool inside the 30s window without triggering a friction strike.
  • maia__diagnose — wraps maia__health with a 4s probe budget and a structured one-line summary. The diagnostic surface for the Maia bridge without parsing raw probe output.
  • concord__tried_approaches — history-of-tried-approaches query. Answers "have I tried this pattern before? what was suggested?" with prior occurrences over a rolling 30-day window. Caps the most-recent list at 20 to bound context cost. Honest aggregation per the M2 contract (CrossInstanceOccurrenceCount is a flag, not a multiplier).
  • concord__record_calibration + concord__calibration_summary — closes the calibration feedback loop. After every concord__verify where the agent self-reported a confidence level, record_calibration appends a (claimed_confidence, actual_outcome) pair to .concord/journal/calibration.jsonl. calibration_summary returns per-level consistency over the last 30 days ("your HIGH-confidence claims were consistent N% of the time").

NEW Server-side friction detection

The Concord MCP server watches for a tool failing twice in a row inside a 30-second window. When it strikes, the next tool response carries a structured _concord_friction field — pattern ID, occurrence count, dedupe key, and a recommended_next_step hint. HMAC-SHA256 signed (per-user key, DACL-locked on Windows / 0600 on POSIX) so injected friction fields are rejected. Per-pattern artifacts land under .concord/friction/<user>/ with a cross-instance occurrence counter.

Three-tier sanitization before any artifact lands on disk: role-spoof lines stripped (system:/assistant:/user:/developer:), injection-directive phrases neutralized, dangerous fenced code blocks (destructive shell, encoded PowerShell, base64-smuggled payloads) replaced with annotations. UTF-8-safe surrogate-pair-preserving truncation at 500 chars.

NEW concord-self-repair skill + apply-side gate

Bundled skill the agent can invoke when a friction pattern points at Concord itself (not your Mendix project). Produces a .patch.DRYRUN file plus a sidecar SHA-256 signature; never auto-applies in v6.2.0. Review with the new tools/apply-concord-patch.ps1 script:

• • Verifies the sidecar signature against the patch bytes in memory
  • Classifies every target path against a 3-tier whitelist: docs auto-eligible, source needs confirm, tests / SKILL.md / concord-* rules / .csproj / .sln / Directory.Build.props / tools/*.ps1 hard-refused
  • Runs git apply --check before applying
  • Archives accepted patches to .concord/applied/
  • TOCTOU-closed via in-memory hash plus script-controlled temp snapshot

A build-time parity test keeps the C# PatchWhitelistValidator regex and the PowerShell apply-script regex in sync; drift fails the build.

NEW Maia bridge resilience trio

The Maia bridge stops asking the agent to babysit it. Five cooperating recovery primitives turn 30-60s wobbles into invisible self-recoveries.

• • Heartbeat auto-reconnect after N failures. When the CDP heartbeat sees the bridge dead for three consecutive beats, it kicks off a background reconnect from its own loop. The agent's next maia__send hits a healthy bridge transparently instead of synchronously paying the 5s connect + 1-2s discovery cost. A single transient blip continues to be a no-op — only persistent failure trips the path.
  • 200ms pre-flight bridge-health probe. Every maia__send / maia__ask / maia__wait / maia__status runs a __maiaBridge.scan() probe with a 200ms budget before the real call. Probe fails → one-shot ResetAsync, then the actual call lands on the reset bridge. Adds ~50ms to the happy path; collapses the "send into a dead bridge, see 5s timeout, manually reset" loop into a transparent one-call recovery.
  • Programmatic Maia-panel auto-reopen via Windows UI Automation. When CdpClient reports "Maia panel not visible," Concord shells out to PowerShell + System.Windows.Automation to find the right-pane TabItem with Name="Maia" in Studio Pro's window tree and invokes SelectionItemPattern.Select() — same call a screen reader makes. Studio Pro instantiates the Maia WebView2 in response. Concord waits 1500ms for the cold-tab render, force-reprobes the router, and retries the send ONCE. The agent's first maia__send is transparently primed — no manual Maia-tab click needed before using the bridge. No Mendix hotkey required (the v6.2.0 first-cut depended on a published shortcut that doesn't exist). On accessibility-tree-blocked configurations the fallback is the canonical "click the Maia tab" guidance.
  • Push-instead-of-poll signal channel. maia_agent.js v3 maintains a per-sentinel signals Map populated atomically when scanForCompletions flips a ticket to done. MaiaActions.WaitAsync drains the fast path first each cycle (__maiaBridge.drainSignal) and falls back to StatusAsync on a null drain. Poll interval halved (250ms → 100ms). Median wait-detection latency drops from ~125ms to ~50ms. True CDP-event push deferred to v6.3.0.
  • Persistent handle store + reissue. Every successful maia__send writes (handle, prompt, sentinel, sent_at) to .concord/state/maia-handles.jsonl via atomic temp + File.Move. MaiaActions.ReissueRecentAsync(maxAge) re-submits every entry younger than the window THROUGH THE ORIGINAL HANDLE so the agent's outstanding maia__wait resolves transparently against the freshly-issued ticket. Auto-fire on heartbeat reconnect lands in v6.3.0.

NEW Monthly digest + tried-approaches journal

The MonthlyDigest reads M1's friction-index.jsonl plus R7's patches.jsonl, projects entries within a UTC half-open month window, and emits .concord/journal/digest-YYYYMM.md. Top-N pattern ranking, recurring-friction surface, patches-by-role grouping, resolved-pattern table. Honest aggregation that respects the M1 CrossInstanceOccurrenceCount flag-vs-multiplier contract.

UX Live status strip + onboarding banner

Always-visible bottom strip in the Concord pane showing Concord MCP port, Studio Pro MCP state, Maia, tab counts, friction on/off, version. 5s poll, "stale" flag after 15s of no response, display-only.

On a project's first Concord open, a single welcome banner points the user at the three flagship tools to try first. Per-project; suppress via HiddenOnboardingBanner in terminal-settings.json. Reuses the existing #banner infrastructure introduced for paste-image acknowledgment — no new chrome surface.

NEW concord-listening.md build rule

Always-loaded into every Claude / Codex / Copilot session in a Concord-wired project. Codifies C1–C5: name failures, consult friction fields, propose different approaches before retrying, calibrate confidence, escalate after two same-tuple failures.

FIX Late-cycle fixes (2026-05-26)

• • concord__diagnose_project project-root resolution. Pre-fix returned no_project even with a project loaded in Studio Pro because the tool only checked Environment.CurrentDirectory — Studio Pro's process cwd is its install dir, not the project root. New three-tier chain: (1) HostServices.App.ProjectPath when the pane has wired the host (canonical), (2) walk up from cwd looking for *.mpr (catches Concord-spawned terminals AND nested subdirs), (3) structured no_project with explicit "pass project_root" guidance. Diagnose-project now succeeds out-of-the-box on any loaded project.
  • Maia panel programmatic activation via Windows UI Automation (described in the resilience-trio section above). The first cut depended on a Mendix hotkey that doesn't exist; UIA replaces it with screen-reader-grade tab-selection via accessibility name. Restores the "agent never sees the wobble" promise of the resilience trio.

Studio Pro Maia panel: operational note

Studio Pro lazy-instantiates the Maia panel's WebView2 on first tab activation. Before any UI click on the Maia tab (manual or automated), the WebView2 control doesn't exist in Studio Pro's tree — the CDP /json endpoint has no maia-agent target to find. This is Studio Pro architectural behavior, not a Concord limitation.

Practical impact: with v6.2.0's UIA-driven activation, the first maia__send in a fresh Studio Pro session transparently activates the Maia tab on your behalf via Windows UI Automation. After that activation, the WebView2 persists for the rest of the Studio Pro session and Maia tools work from any right-pane tab. If your machine's accessibility tree access is blocked (rare — some hardened endpoints), the agent will report the canonical "click the Maia tab in the right pane" error and you can prime it once manually.

Durability + safety

• • M1 FrictionJournal uses a cross-process named mutex (Concord.Journal.<sha256(project)[..16]>) so two open Concord panes in the same project serialize their journal writes. Per-port partition files (friction-index.<port>.jsonl) handle mutex-timeout fallback; the MonthlyDigest reader unions all partitions so partition-fallback data is never lost.
  • R7 patches are SHA-256 signed (sidecar) and the apply script verifies bytes in memory before snapshotting to a script-controlled temp file. Closes the TOCTOU window that an attacker with write access to .concord/ could otherwise use.
  • HMAC-SHA256 friction signing uses a per-user 32-byte key with on-disk DACL lockdown so injected friction can't survive the verify step.
  • Maia heartbeat auto-recovery never auto-resets reflexively. The router-side rule has been updated so the agent does NOT call maia__reset on a single timeout — only after maia__health confirms a persistent degraded transport.

Compatibility

Same as v6.1.x: Studio Pro 10.24.13 (10.x LTS floor — no Maia) and 11.10.0 or newer (full feature set, Maia on Windows). Windows 10 build 17763 (1809)+ or macOS 10.15 (Catalina)+. .NET 8 (bundled).

Internal By the numbers

• • 780+ unit tests passing in the C# suite (Terminal.Tests + Concord.Core.Tests, 3 Maia-live skipped). Net additions in v6.2.0: friction subsystem (131), verify gate (25), self-repair (60), diagnostics (7), briefing (7), tool discovery (11), memory journal (8), task-context pruning (24), Maia resilience trio (24), monthly digest + history + calibration (~25 across M2 + M3 + M5).
  • New code-organization seams: Concord.Core/Memory/, Concord.Core/Repair/, Concord.Core/Friction/ all formalized in this cycle.
  • Build rule and skill installation flow unchanged from v6.1.x — the new concord-listening.md rule and concord-self-repair skill drop in via the existing RulesInstaller + SkillInstaller enumeration.

Known v6.3.0 follow-ups

• • C2 NarrationEnforcer + C3 _concord_completion_malformed detector. Both require either CLI transcript hooks OR a new concord__complete tool-form completion-report surface.
  • M4 patterns dashboard. WebView surface visualizing M1 friction trends + M3 tried-approaches history + M5 calibration consistency. All upstream data plumbing is now landed and ready to render.
  • C6 listening-plane test coverage. 8 fixture-driven scenarios plus mocked-LLM driver primitive. Blocks on the C2/C3 architecture call.
  • R7 orchestrator wire-up (auto-spawn concord-self-repair subagent on second-strike) — kept manual in v6.2.0 for safety.
  • Maia handle-store auto-reissue on heartbeat reconnect — the CdpClient.OnReconnected event + pane wire-up is the integration step; ReissueRecentAsync ships as the manually-invocable primitive.
  • Retire MaiaRouter.NormalizeHandle bracket-tolerance backstop once telemetry confirms zero legacy-fallback hits.
  • True CDP-event push (one-shot listener via Runtime.consoleAPICalled) replacing the v6.2.0 batch-poll signal drain.

Upgrade notes

The terminal-settings.json schema gains two new optional fields (EnableFriction defaulted true, HiddenOnboardingBanner defaulted false). Existing settings files load fine — both fields use the optional-default-passthrough pattern. Sticky-opt-out preserves EnableFriction across upgrades; HiddenOnboardingBanner is not sticky-tracked (it survives via the natural loaded with { ... } passthrough in MergeUpgradeWithStickies).

Version: 6.2.0

Framework Version: 10.24.13

Release Notes:

Concord 6.2.0 — Concord Intelligence

The bridge now actively helps the agent stay un-stuck. Six new MCP tools the agent calls itself, a server-side friction-detection layer that hands the agent a structured "you tried this twice — try something different" hint, a self-repair skill that lets the agent propose a unified-diff patch to Concord itself when the bridge is at fault, and a Maia resilience trio (heartbeat auto-reconnect, pre-flight bridge-health probe, programmatic Maia-panel auto-reopen) that turns 30-60s wobbles into invisible self-recoveries. Plus a live status strip, a first-5-minutes onboarding banner, and a monthly digest that rolls up what hurt across a project's month.

This is the cycle where Concord stops being a passive transport and starts being a participant.

Zero breaking changes for upgrades from v6.1.x. Settings persisted from v6.1.x carry forward unchanged; two new optional fields (EnableFriction defaulted true, HiddenOnboardingBanner defaulted false) merge through the existing optional-default passthrough.

What's new

NEW Six new MCP orientation + verification tools

• • concord__session_context — one-call project briefing. Returns a 6-section orientation (identity, project, tooling, friction policy, listening posture, known limits) so the agent's first turn no longer has to play 20 questions.
  • concord__find_tool — semantic tool discovery. The agent describes what it's trying to do ("create a microflow that returns the active user") and gets the right tool name back with rationale. Replaces tool-name guessing.
  • concord__diagnose_project — 7 parallel health probes (entity graph, microflow refs, theme integrity, MCP wiring, Maia reachability, ports, settings hygiene) under a 4-second total budget. Tells the agent what's wrong before it burns calls on a broken slot.
  • concord__verify — recipe-driven post-action verification. The agent declares "I just created entity X" and verify runs the entity_created recipe and tells the agent whether the model actually contains it now.
  • concord__set_task_context — task-scoped tool catalog pruning. The agent declares its current task family ("editing-microflows") and the catalog hides irrelevant tools so the next tool-search ranks faster.
  • concord__silence_friction — per-tool false-positive opt-out for the friction layer. When the agent legitimately needs to retry a tool inside the 30s window without triggering a friction strike.
  • maia__diagnose — wraps maia__health with a 4s probe budget and a structured one-line summary. The diagnostic surface for the Maia bridge without parsing raw probe output.
  • concord__tried_approaches — history-of-tried-approaches query. Answers "have I tried this pattern before? what was suggested?" with prior occurrences over a rolling 30-day window. Caps the most-recent list at 20 to bound context cost. Honest aggregation per the M2 contract (CrossInstanceOccurrenceCount is a flag, not a multiplier).
  • concord__record_calibration + concord__calibration_summary — closes the calibration feedback loop. After every concord__verify where the agent self-reported a confidence level, record_calibration appends a (claimed_confidence, actual_outcome) pair to .concord/journal/calibration.jsonl. calibration_summary returns per-level consistency over the last 30 days ("your HIGH-confidence claims were consistent N% of the time").

NEW Server-side friction detection

The Concord MCP server watches for a tool failing twice in a row inside a 30-second window. When it strikes, the next tool response carries a structured _concord_friction field — pattern ID, occurrence count, dedupe key, and a recommended_next_step hint. HMAC-SHA256 signed (per-user key, DACL-locked on Windows / 0600 on POSIX) so injected friction fields are rejected. Per-pattern artifacts land under .concord/friction// with a cross-instance occurrence counter.

Three-tier sanitization before any artifact lands on disk: role-spoof lines stripped (system:/assistant:/user:/developer:), injection-directive phrases neutralized, dangerous fenced code blocks (destructive shell, encoded PowerShell, base64-smuggled payloads) replaced with annotations. UTF-8-safe surrogate-pair-preserving truncation at 500 chars.

NEW concord-self-repair skill + apply-side gate

Bundled skill the agent can invoke when a friction pattern points at Concord itself (not your Mendix project). Produces a .patch.DRYRUN file plus a sidecar SHA-256 signature; never auto-applies in v6.2.0. Review with the new tools/apply-concord-patch.ps1 script:

• • Verifies the sidecar signature against the patch bytes in memory
  • Classifies every target path against a 3-tier whitelist: docs auto-eligible, source needs confirm, tests / SKILL.md / concord-* rules / .csproj / .sln / Directory.Build.props / tools/*.ps1 hard-refused
  • Runs git apply --check before applying
  • Archives accepted patches to .concord/applied/
  • TOCTOU-closed via in-memory hash plus script-controlled temp snapshot

A build-time parity test keeps the C# PatchWhitelistValidator regex and the PowerShell apply-script regex in sync; drift fails the build.

NEW Maia bridge resilience trio

The Maia bridge stops asking the agent to babysit it. Five cooperating recovery primitives turn 30-60s wobbles into invisible self-recoveries.

• • Heartbeat auto-reconnect after N failures. When the CDP heartbeat sees the bridge dead for three consecutive beats, it kicks off a background reconnect from its own loop. The agent's next maia__send hits a healthy bridge transparently instead of synchronously paying the 5s connect + 1-2s discovery cost. A single transient blip continues to be a no-op — only persistent failure trips the path.
  • 200ms pre-flight bridge-health probe. Every maia__send / maia__ask / maia__wait / maia__status runs a __maiaBridge.scan() probe with a 200ms budget before the real call. Probe fails → one-shot ResetAsync, then the actual call lands on the reset bridge. Adds ~50ms to the happy path; collapses the "send into a dead bridge, see 5s timeout, manually reset" loop into a transparent one-call recovery.
  • Programmatic Maia-panel auto-reopen via Windows UI Automation. When CdpClient reports "Maia panel not visible," Concord shells out to PowerShell + System.Windows.Automation to find the right-pane TabItem with Name="Maia" in Studio Pro's window tree and invokes SelectionItemPattern.Select() — same call a screen reader makes. Studio Pro instantiates the Maia WebView2 in response. Concord waits 1500ms for the cold-tab render, force-reprobes the router, and retries the send ONCE. The agent's first maia__send is transparently primed — no manual Maia-tab click needed before using the bridge. No Mendix hotkey required (the v6.2.0 first-cut depended on a published shortcut that doesn't exist). On accessibility-tree-blocked configurations the fallback is the canonical "click the Maia tab" guidance.
  • Push-instead-of-poll signal channel. maia_agent.js v3 maintains a per-sentinel signals Map populated atomically when scanForCompletions flips a ticket to done. MaiaActions.WaitAsync drains the fast path first each cycle (__maiaBridge.drainSignal) and falls back to StatusAsync on a null drain. Poll interval halved (250ms → 100ms). Median wait-detection latency drops from ~125ms to ~50ms. True CDP-event push deferred to v6.3.0.
  • Persistent handle store + reissue. Every successful maia__send writes (handle, prompt, sentinel, sent_at) to .concord/state/maia-handles.jsonl via atomic temp + File.Move. MaiaActions.ReissueRecentAsync(maxAge) re-submits every entry younger than the window THROUGH THE ORIGINAL HANDLE so the agent's outstanding maia__wait resolves transparently against the freshly-issued ticket. Auto-fire on heartbeat reconnect lands in v6.3.0.

NEW Monthly digest + tried-approaches journal

The MonthlyDigest reads M1's friction-index.jsonl plus R7's patches.jsonl, projects entries within a UTC half-open month window, and emits .concord/journal/digest-YYYYMM.md. Top-N pattern ranking, recurring-friction surface, patches-by-role grouping, resolved-pattern table. Honest aggregation that respects the M1 CrossInstanceOccurrenceCount flag-vs-multiplier contract.

UX Live status strip + onboarding banner

Always-visible bottom strip in the Concord pane showing Concord MCP port, Studio Pro MCP state, Maia, tab counts, friction on/off, version. 5s poll, "stale" flag after 15s of no response, display-only.

On a project's first Concord open, a single welcome banner points the user at the three flagship tools to try first. Per-project; suppress via HiddenOnboardingBanner in terminal-settings.json. Reuses the existing #banner infrastructure introduced for paste-image acknowledgment — no new chrome surface.

NEW concord-listening.md build rule

Always-loaded into every Claude / Codex / Copilot session in a Concord-wired project. Codifies C1–C5: name failures, consult friction fields, propose different approaches before retrying, calibrate confidence, escalate after two same-tuple failures.

FIX Late-cycle fixes (2026-05-26)

• • concord__diagnose_project project-root resolution. Pre-fix returned no_project even with a project loaded in Studio Pro because the tool only checked Environment.CurrentDirectory — Studio Pro's process cwd is its install dir, not the project root. New three-tier chain: (1) HostServices.App.ProjectPath when the pane has wired the host (canonical), (2) walk up from cwd looking for *.mpr (catches Concord-spawned terminals AND nested subdirs), (3) structured no_project with explicit "pass project_root" guidance. Diagnose-project now succeeds out-of-the-box on any loaded project.
  • Maia panel programmatic activation via Windows UI Automation (described in the resilience-trio section above). The first cut depended on a Mendix hotkey that doesn't exist; UIA replaces it with screen-reader-grade tab-selection via accessibility name. Restores the "agent never sees the wobble" promise of the resilience trio.

Studio Pro Maia panel: operational note

Studio Pro lazy-instantiates the Maia panel's WebView2 on first tab activation. Before any UI click on the Maia tab (manual or automated), the WebView2 control doesn't exist in Studio Pro's tree — the CDP /json endpoint has no maia-agent target to find. This is Studio Pro architectural behavior, not a Concord limitation.

Practical impact: with v6.2.0's UIA-driven activation, the first maia__send in a fresh Studio Pro session transparently activates the Maia tab on your behalf via Windows UI Automation. After that activation, the WebView2 persists for the rest of the Studio Pro session and Maia tools work from any right-pane tab. If your machine's accessibility tree access is blocked (rare — some hardened endpoints), the agent will report the canonical "click the Maia tab in the right pane" error and you can prime it once manually.

Durability + safety

• • M1 FrictionJournal uses a cross-process named mutex (Concord.Journal.) so two open Concord panes in the same project serialize their journal writes. Per-port partition files (friction-index..jsonl) handle mutex-timeout fallback; the MonthlyDigest reader unions all partitions so partition-fallback data is never lost.
  • R7 patches are SHA-256 signed (sidecar) and the apply script verifies bytes in memory before snapshotting to a script-controlled temp file. Closes the TOCTOU window that an attacker with write access to .concord/ could otherwise use.
  • HMAC-SHA256 friction signing uses a per-user 32-byte key with on-disk DACL lockdown so injected friction can't survive the verify step.
  • Maia heartbeat auto-recovery never auto-resets reflexively. The router-side rule has been updated so the agent does NOT call maia__reset on a single timeout — only after maia__health confirms a persistent degraded transport.

Compatibility

Same as v6.1.x: Studio Pro 10.24.13 (10.x LTS floor — no Maia) and 11.10.0 or newer (full feature set, Maia on Windows). Windows 10 build 17763 (1809)+ or macOS 10.15 (Catalina)+. .NET 8 (bundled).

Internal By the numbers

• • 780+ unit tests passing in the C# suite (Terminal.Tests + Concord.Core.Tests, 3 Maia-live skipped). Net additions in v6.2.0: friction subsystem (131), verify gate (25), self-repair (60), diagnostics (7), briefing (7), tool discovery (11), memory journal (8), task-context pruning (24), Maia resilience trio (24), monthly digest + history + calibration (~25 across M2 + M3 + M5).
  • New code-organization seams: Concord.Core/Memory/, Concord.Core/Repair/, Concord.Core/Friction/ all formalized in this cycle.
  • Build rule and skill installation flow unchanged from v6.1.x — the new concord-listening.md rule and concord-self-repair skill drop in via the existing RulesInstaller + SkillInstaller enumeration.

Known v6.3.0 follow-ups

• • C2 NarrationEnforcer + C3 _concord_completion_malformed detector. Both require either CLI transcript hooks OR a new concord__complete tool-form completion-report surface.
  • M4 patterns dashboard. WebView surface visualizing M1 friction trends + M3 tried-approaches history + M5 calibration consistency. All upstream data plumbing is now landed and ready to render.
  • C6 listening-plane test coverage. 8 fixture-driven scenarios plus mocked-LLM driver primitive. Blocks on the C2/C3 architecture call.
  • R7 orchestrator wire-up (auto-spawn concord-self-repair subagent on second-strike) — kept manual in v6.2.0 for safety.
  • Maia handle-store auto-reissue on heartbeat reconnect — the CdpClient.OnReconnected event + pane wire-up is the integration step; ReissueRecentAsync ships as the manually-invocable primitive.
  • Retire MaiaRouter.NormalizeHandle bracket-tolerance backstop once telemetry confirms zero legacy-fallback hits.
  • True CDP-event push (one-shot listener via Runtime.consoleAPICalled) replacing the v6.2.0 batch-poll signal drain.

Upgrade notes

The terminal-settings.json schema gains two new optional fields (EnableFriction defaulted true, HiddenOnboardingBanner defaulted false). Existing settings files load fine — both fields use the optional-default-passthrough pattern. Sticky-opt-out preserves EnableFriction across upgrades; HiddenOnboardingBanner is not sticky-tracked (it survives via the natural loaded with { ... } passthrough in MergeUpgradeWithStickies).