Refresh Linear-only issue tracking policy

docs/guide/development/issue_labeling.md

@@ -1,12 +1,18 @@
 # Issue Labeling
 
-Goal: Standardize how GitHub issues are labeled in this repository.
-Read this when: You are creating, revising, or auditing issue labels and issue triage.
-Inputs: The current GitHub issue tracker plus the repository's issue taxonomy needs.
+Goal: Standardize how Linear issues are labeled in this repository.
+Read this when: You are creating, revising, or auditing Linear labels and issue triage.
+Inputs: The current Linear workspace labels plus the repository's issue taxonomy needs.
 Depends on: Existing label groups and the repository's development workflow.
 Verification: Labels remain consistent, searchable, and aligned with the documented taxonomy.
 
-This guide standardizes how GitHub issues are labeled in this repository.
+This guide standardizes how Linear issues are labeled in this repository.
+
+Tracker policy:
+
+- Linear is the authoritative issue tracker for planning, triage, and delivery.
+- GitHub remains the code hosting, pull request review, release, and CI surface.
+- GitHub Issues are not part of the planning, triage, or delivery workflow.
 
 ## Goals
 
@@ -97,6 +103,6 @@ These labels exist for automation and should not be repurposed.
 
 ## Query patterns
 
-- All epics: `label:kind:epic`.
-- Open feature work: `label:kind:feat is:open`.
-- Reliability issues in storage: `label:area:storage label:theme:reliability`.
+- All epics: `kind:epic`.
+- Open feature work: `kind:feat` with non-completed workflow state.
+- Reliability issues in storage: `area:storage` + `theme:reliability`.

docs/guide/evaluation.md

@@ -218,7 +218,7 @@ Operational notes:
 
 ## Search Modes Latency Benchmark
 
-To validate the Issue #58 acceptance criterion that `quick_find` has **lower p95 latency** than
+To validate the search-modes acceptance criterion that `quick_find` has **lower p95 latency** than
 `planned_search`, run a small benchmark using `elf-eval` search-mode selection.
 
 This procedure uses the ranking-stability harness to seed a deterministic dataset (local providers),

docs/plans/2026-02-10-structured-memory-fields-design.md

@@ -1,4 +1,4 @@
-# Structured Memory Fields With Field-Level Embeddings (Issue #17)
+# Structured Memory Fields With Field-Level Embeddings
 
 ## Goal
 Improve semantic precision on fact-like queries by adding optional structured fields to notes (summary, facts, concepts), embedding them separately, and merging field matches back into a single note result with explicit explain output.
@@ -35,4 +35,3 @@ Explain output includes `matched_fields` entries for matched structured fields.
 ## Testing And Evaluation
 - Unit tests cover structured-field validation and evidence binding for facts.
 - Add a small evaluation dataset focused on fact-like queries and run `elf-eval` before/after enabling structured-field retrieval to compare precision and false positives.
-

docs/plans/2026-02-22-org-shared-implementation-plan.md

@@ -30,7 +30,7 @@
 **Step 4: Commit (optional)**
 ```bash
 git add packages/elf-service/src/access.rs packages/elf-service/src/sharing.rs docs/spec/system_elf_memory_service_v2.md
-git commit -m '{"schema":"cmsg/1","type":"feat","scope":"sharing","summary":"Define org sentinel project id","intent":"Add a reserved project id for org_shared storage","impact":"Centralizes __org__ constant for later org_shared semantics","breaking":false,"risk":"low","refs":["gh:hack-ink/ELF#72"]}'
+git commit -m '{"schema":"cmsg/1","type":"feat","scope":"sharing","summary":"Define org sentinel project id","intent":"Add a reserved project id for org_shared storage","impact":"Centralizes __org__ constant for later org_shared semantics","breaking":false,"risk":"low","refs":[]}'
 ```
 
 ### Task 2: Propagate auth role to request handling (static_keys mode)
@@ -154,4 +154,3 @@ Two execution options:
 2) **Parallel Session (separate)** — open a new session and execute with `executing-plans` checkpoints
 
 Which approach do you want?
-

docs/plans/2026-03-01-reflection-consolidation-loop-eval-scenarios.md

@@ -2,7 +2,7 @@
 
 ## Decision
 
-For issue #79 we define consolidation as an **agent-side policy** and keep **scoring and API behavior as server-side capability**.
+For the reflection/consolidation loop track we define consolidation as an **agent-side policy** and keep **scoring and API behavior as server-side capability**.
 
 The agent decides when to consolidate (`query + merge policy`), while `elf-api`/`elf-worker` only provide:
 

docs/spec/system_elf_memory_service_v2.md

@@ -3,7 +3,7 @@
 Purpose: Define the ELF Memory Service v2.0 contract, invariants, and storage model.
 Status: normative
 Read this when: You are implementing, validating, or reviewing the core ELF memory service behavior.
-Not this document: Operator runbooks, local setup steps, or issue-triage workflows.
+Not this document: Operator runbooks, local setup steps, or work-item triage workflows.
 Defines: ELF Memory Service v2.0 API semantics, ingestion boundaries, and storage invariants.
 
 Description: ELF means Evidence-linked fact memory for agents.
@@ -1270,7 +1270,7 @@ Behavior:
 - Allowed status transitions: pending->active, pending->deprecated, active->deprecated.
 - Deprecated predicates cannot be modified (409).
 - Global predicates are immutable (403).
-- Note: Global predicate mutations require follow-up #68.
+- Note: Global predicate mutations remain follow-up work and are not covered by this contract.
 
 Response:
 {
@@ -1302,7 +1302,7 @@ Behavior:
 - alias must be non-empty.
 - Deprecated predicates cannot be modified (409).
 - Global predicates are immutable (403).
-- Note: Global predicate mutations require follow-up #68.
+- Note: Global predicate mutations remain follow-up work and are not covered by this contract.
 
 Response:
 {