Feature/notation note entry

.gitignore

@@ -28,3 +28,9 @@ dist/
 # Others
 AGENTS.local.md
 .codex/
+
+# Graphify
+graphify-out/
+
+# Xcode asset catalog metadata
+**/*.xcassets/

AGENTS.md

@@ -116,3 +116,96 @@ Do not use vague names such as `ai-work`, `codex-fix`, `changes`, `update`, or `
 - Audio access uses security-scoped bookmarks.
 - Recent projects are stored in user defaults and capped to 10 entries.
 - Project load must normalize/clamp duration-dependent state: beat grid, loop range, notes, regions, playback rate, pitch shift, and tempo.
+
+## Documentation lookup
+
+When working with Swift, SwiftUI, AppKit, AVFoundation, AVAudioEngine, CoreAudio, macOS sandboxing, GitHub Actions, or packaging, use Context7 to check current documentation before proposing or implementing changes.
+
+Prefer Context7 documentation lookup for:
+- Swift language APIs
+- SwiftUI macOS components
+- AppKit interoperability
+- AVFoundation and AVAudioEngine
+- macOS sandboxing and entitlements
+- GitHub Actions and release packaging
+
+When documentation is relevant, mention briefly which API or library was checked.
+
+## Test review workflow
+
+For implementation tasks that create, modify, rename, or delete source files, test files, project files, or behavior-affecting configuration:
+
+1. After the implementation is complete and before the final report, spawn the `test_reviewer` subagent.
+2. The `test_reviewer` subagent must be read-only and must not edit files.
+3. Ask `test_reviewer` to review:
+   - missing tests;
+   - weak or misleading tests;
+   - likely regressions not covered by tests;
+   - flaky or timing-sensitive tests;
+   - async/concurrency test risks;
+   - whether existing tests need updates.
+4. Wait for the review result.
+5. Address valid test reviewer findings before the final report when the fix is in scope.
+6. If a reviewer finding is rejected or deferred, explain why briefly in the final report.
+
+Use `test_reviewer` especially for changes involving:
+- Swift model or business logic;
+- SwiftUI state behavior;
+- AVAudioEngine, AVFoundation, CoreAudio, playback, timing, waveform rendering, BPM/key detection, or metronome logic;
+- MusicXML, notation, harmony, markers, regions, beats, measures, or time-signature logic;
+- persistence, project loading/saving, import/export, or migrations;
+- bug fixes;
+- refactoring that could change behavior.
+
+Do not spawn `test_reviewer` for pure analysis-only tasks, DISCUSS mode, documentation-only edits, comment-only edits, or formatting-only changes unless tests are explicitly part of the request.
+
+The main agent owns the final decision.
+The main agent must not silently ignore `test_reviewer` findings.
+
+## Maintainability review workflow
+
+For implementation tasks that create, modify, rename, or delete source files, project files, or behavior-affecting configuration:
+
+1. After the implementation is complete and before the final report, spawn the `maintainability_reviewer` subagent.
+2. The `maintainability_reviewer` subagent must be read-only and must not edit files.
+3. Ask `maintainability_reviewer` to review:
+   - maintainability risks;
+   - avoidable complexity;
+   - duplicated logic;
+   - unclear ownership boundaries;
+   - unnecessary coupling;
+   - premature or weak abstractions;
+   - oversized functions, types, SwiftUI views, services, or managers;
+   - duplicated or inconsistent state;
+   - whether a smaller refactor should be done before finalizing.
+4. Wait for the review result.
+5. Address valid maintainability reviewer findings before the final report when the fix is in scope.
+6. If a reviewer finding is rejected or deferred, explain why briefly in the final report.
+
+Use `maintainability_reviewer` especially for changes involving:
+- SwiftUI views or custom controls;
+- state management;
+- timeline, waveform, markers, regions, notation, harmony, or MusicXML logic;
+- AVAudioEngine, AVFoundation, CoreAudio, playback, timing, BPM/key detection, or metronome logic;
+- persistence, project loading/saving, import/export, or migrations;
+- refactoring tasks;
+- new services, managers, protocols, models, or shared utilities;
+- changes that touch several files or architectural boundaries.
+
+Do not spawn `maintainability_reviewer` for pure analysis-only tasks, DISCUSS mode, documentation-only edits, comment-only edits, formatting-only changes, or trivial one-line fixes unless maintainability/refactoring review is explicitly requested.
+
+The main agent owns the final decision.
+The main agent must not silently ignore `maintainability_reviewer` findings.
+
+## graphify
+
+This project has a knowledge graph at graphify-out/ with god nodes, community structure, and cross-file relationships.
+
+When the user types `/graphify`, use the installed graphify skill or instructions before doing anything else.
+
+Rules:
+- For codebase questions, first run `graphify query "<question>"` when graphify-out/graph.json exists. Use `graphify path "<A>" "<B>"` for relationships and `graphify explain "<concept>"` for focused concepts. These return a scoped subgraph, usually much smaller than GRAPH_REPORT.md or raw grep output.
+- Dirty graphify-out/ files are expected after hooks or incremental updates; dirty graph files are not a reason to skip graphify. Only skip graphify if the task is about stale or incorrect graph output, or the user explicitly says not to use it.
+- If graphify-out/wiki/index.md exists, use it for broad navigation instead of raw source browsing.
+- Read graphify-out/GRAPH_REPORT.md only for broad architecture review or when query/path/explain do not surface enough context.
+- After modifying code, run `graphify update .` to keep the graph current (AST-only, no API cost).

CHANGELOG.md

@@ -8,8 +8,22 @@ development artifact builds use `vMAJOR.MINOR.PATCH-dev.N`.
 
 ## Unreleased
 
+- Added tied-note entry with the `T` shortcut, Leland-based controls, automatic note splitting and tie chains across measure boundaries, selected-note continuation outside note-entry mode, blocked-state tooltips without system alert sounds, score rendering, project persistence, and MusicXML export.
+- Added persistent augmentation-dot entry and editing for Notation notes and rests, with Leland glyphs, keyboard shortcuts, and MusicXML export.
+- Added sixteenth-note and rest entry with `3`/`Num3` duration shortcuts, plus downward stems for notes above the middle staff line.
+- Added Notation note-entry mode for placing pitched notes with Leland-rendered note glyphs, note selection preview, cross-rest insertion, rest recomposition, and MusicXML export.
+- Expanded Notation entry to ledger-line pitches from G3 through D6 and added rest-entry controls for inserting selected rest durations.
+- Added Notation note editing for dragging note pitch, arrow-key pitch changes, and deleting selected notes back to rests.
+- Added per-stem Notation parts with collapsible stem notation tracks, score-aligned multi-part Notation systems, shared Region labels, part visibility controls, and multi-part MusicXML export.
 - Added clearer hover tooltips and numpad shortcuts for Notation duration buttons.
 - Added a bar/beat position readout to the transport time display.
+- Fixed multi-part Notation accessibility selection announcements and prevented harmony editing from clearing a selected stem note.
+- Prevented an oversized Notation duration change from removing later notes or rests in the measure.
+- Stabilized the Rest entry icon, matched Notation track controls, aligned stem Mute/Solo buttons, and limited MusicXML export to the selected Parts.
+- Added full instrument names, abbreviations, and standard instrument sounds to exported MusicXML parts and Notation score labels.
+- Added vertical workspace scrolling when expanded Notation tracks exceed the main window height.
+- Changed Rest entry mode to replace a selected note with its corresponding rest without recomposing the measure.
+- Added per-part treble and bass clefs with Leland glyphs, clef-aware note editing, pitch transposition, and MusicXML export.
 
 ## 1.1.0
 

Configurations/Base.xcconfig

@@ -4,6 +4,7 @@
 PRODUCT_NAME = $(TARGET_NAME)
 MACOSX_DEPLOYMENT_TARGET = 14.0
 SWIFT_VERSION = 5.0
+SWIFT_STRICT_CONCURRENCY = targeted
 SDKROOT = macosx
 CLANG_CXX_LANGUAGE_STANDARD = gnu++20
 GCC_C_LANGUAGE_STANDARD = gnu17