}
}
diff --git a/openspec/changes/fix-results-list-undefined-center/.openspec.yaml b/openspec/changes/fix-results-list-undefined-center/.openspec.yaml
new file mode 100644
index 0000000000..38f76288a8
--- /dev/null
+++ b/openspec/changes/fix-results-list-undefined-center/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-06-22
diff --git a/openspec/changes/fix-results-list-undefined-center/design.md b/openspec/changes/fix-results-list-undefined-center/design.md
new file mode 100644
index 0000000000..ac83ea0eed
--- /dev/null
+++ b/openspec/changes/fix-results-list-undefined-center/design.md
@@ -0,0 +1,30 @@
+## Context
+
+The results list table (`results-list.component.html`) renders the **Center** column from each result's `lead_center` field. The current binding (line 124) is:
+
+```html
+column.attr === 'lead_center' ? (subResult.lead_center || 'Undefined') : ...
+```
+
+When `lead_center` is falsy (null / empty — which happens when the result is led by an external partner, not a CGIAR center), the `|| 'Undefined'` branch renders the literal string `"Undefined"`. QA reported this as P2-3049.
+
+## Goals / Non-Goals
+
+**Goals:**
+- The Center cell renders **blank** (empty string) when a result has no lead center.
+- Document, in code, the future intent to display the lead partner when no center exists.
+
+**Non-Goals:**
+- Resolving and displaying the actual lead partner name when `lead_center` is absent (future change).
+- Any backend / API / payload changes.
+- Touching the IPSR list (it has no `lead_center` column — verified).
+
+## Decisions
+
+- **Minimal template fix:** change the fallback `'Undefined'` to `''` in the existing ternary. No new component logic, no pipe, no service change — keeps the fix quirurgical and low-risk.
+- **Document future scope inline:** add a `TODO (P2-3049)` HTML comment next to the binding so the next developer knows the empty cell is intentional and that the long-term behavior is to fall back to the lead partner.
+
+## Risks / Trade-offs
+
+- **Empty cell vs. placeholder:** showing a blank cell (instead of e.g. a dash) is the explicitly requested behavior. Trade-off accepted: a blank cell reads as "no center" rather than a broken value.
+- Very low risk: single-line template change, no behavioral change for results that *do* have a lead center.
diff --git a/openspec/changes/fix-results-list-undefined-center/proposal.md b/openspec/changes/fix-results-list-undefined-center/proposal.md
new file mode 100644
index 0000000000..b98b8d3df8
--- /dev/null
+++ b/openspec/changes/fix-results-list-undefined-center/proposal.md
@@ -0,0 +1,24 @@
+## Why
+
+In the results list table, the **Center** column shows the literal text `"Undefined"` whenever a result has no lead center. This happens when the result is led by an **external partner** (not a CGIAR center), so the backend returns an empty/null `lead_center`. The template falls back to the hardcoded string `'Undefined'`, which is confusing for users and was reported as a QA bug (P2-3049).
+
+## What Changes
+
+- Replace the hardcoded fallback `|| 'Undefined'` with an **empty string** `''` so the Center cell renders blank instead of `"Undefined"` when there is no lead center.
+- Leave a code `TODO (P2-3049)` comment documenting that a future change should display the **lead partner** in this column when no lead center exists (i.e. take partners into account, not only centers).
+
+Out of scope (documented for the future, not implemented now): actually resolving and rendering the lead partner name when `lead_center` is absent.
+
+## Capabilities
+
+### New Capabilities
+- `results-list-center-column`: Defines how the Center column of the results list renders a result's lead center, including the empty-state behavior when no lead center exists.
+
+### Modified Capabilities
+
+
+## Impact
+
+- Frontend only. Single template line + a code comment.
+- File: `onecgiar-pr-client/src/app/pages/results/pages/results-outlet/pages/results-list/results-list.component.html` (line 124).
+- No backend, API, or data-model changes. No new dependencies.
diff --git a/openspec/changes/fix-results-list-undefined-center/specs/results-list-center-column/spec.md b/openspec/changes/fix-results-list-undefined-center/specs/results-list-center-column/spec.md
new file mode 100644
index 0000000000..9b3dbedb27
--- /dev/null
+++ b/openspec/changes/fix-results-list-undefined-center/specs/results-list-center-column/spec.md
@@ -0,0 +1,25 @@
+## ADDED Requirements
+
+### Requirement: Center column empty state
+
+The Center column of the results list SHALL display the result's lead center name when a lead center exists, and SHALL render an empty cell (no text) when the result has no lead center. The column MUST NOT render the literal text `"Undefined"`.
+
+#### Scenario: Result has a lead center
+
+- **WHEN** a result has a non-empty `lead_center` value
+- **THEN** the Center column displays that `lead_center` value
+
+#### Scenario: Result has no lead center (led by an external partner)
+
+- **WHEN** a result's `lead_center` is null or empty
+- **THEN** the Center column renders an empty cell
+- **AND** the literal text `"Undefined"` is never shown
+
+### Requirement: Documented future fallback to lead partner
+
+The code SHALL carry a documented note (TODO referencing P2-3049) indicating that, in a future change, the Center column is expected to fall back to displaying the result's lead partner when no lead center exists.
+
+#### Scenario: Developer reads the Center column binding
+
+- **WHEN** a developer inspects the Center column template binding
+- **THEN** a comment documents that the empty cell is intentional and that the future behavior is to display the lead partner instead
diff --git a/openspec/changes/fix-results-list-undefined-center/tasks.md b/openspec/changes/fix-results-list-undefined-center/tasks.md
new file mode 100644
index 0000000000..cc9d6d84c0
--- /dev/null
+++ b/openspec/changes/fix-results-list-undefined-center/tasks.md
@@ -0,0 +1,9 @@
+## 1. Fix the Center column fallback
+
+- [x] 1.1 In `onecgiar-pr-client/src/app/pages/results/pages/results-outlet/pages/results-list/results-list.component.html` (line ~124), change the `lead_center` fallback from `|| 'Undefined'` to `|| ''` so an empty cell is rendered when there is no lead center.
+- [x] 1.2 Add a `TODO (P2-3049)` HTML comment next to the binding documenting that the empty cell is intentional and that a future change should display the lead partner when no lead center exists.
+
+## 2. Verify
+
+- [x] 2.1 Verify a result with a lead center still shows the center name. (Confirmed locally: e.g. "ICARDA" renders.)
+- [x] 2.2 Verify a result led by an external partner (no lead center) shows a blank cell, not `"Undefined"`. (Confirmed locally: empty cells, no "Undefined" anywhere on the page.)
diff --git a/openspec/changes/p2-3053-dynamic-reporting-phase-year/.openspec.yaml b/openspec/changes/p2-3053-dynamic-reporting-phase-year/.openspec.yaml
new file mode 100644
index 0000000000..38f76288a8
--- /dev/null
+++ b/openspec/changes/p2-3053-dynamic-reporting-phase-year/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-06-22
diff --git a/openspec/changes/p2-3053-dynamic-reporting-phase-year/design.md b/openspec/changes/p2-3053-dynamic-reporting-phase-year/design.md
new file mode 100644
index 0000000000..ba184a43af
--- /dev/null
+++ b/openspec/changes/p2-3053-dynamic-reporting-phase-year/design.md
@@ -0,0 +1,40 @@
+## Context
+
+The Reporting-by-ToC views render a phase header and an HLO indicator table. The phase year is written as the literal string `2025` in the templates and in the shared table's column config, so opening the 2026 phase did not update them. The active phase year is already available app-wide via `DataControlService.reportingCurrentPhase.phaseYear` (set in `getCurrentPhases()` from `GET_versioning(OPEN, REPORTING)`), and is reached in components through the `ApiService` aggregator (`api.dataControlSE.reportingCurrentPhase.phaseYear`).
+
+## Goals / Non-Goals
+
+**Goals:**
+- The phase header and target-column year in the three Reporting-by-ToC views show the active phase year dynamically.
+- No hardcoded year remains in the affected templates/configs.
+
+**Non-Goals:**
+- No nomenclature changes (Indicator name → HLO title, KPI statement, typology, targets) — separate scope, tagged to Santi + Ángel.
+- No change to `indicator-details` "2024" label or the backend `achieved_in_2024` field.
+- No change to the `outcome-indicator-home` "2022-2024" baseline text.
+- No "all P/A" rollout beyond what these shared components already cover.
+
+## Decisions
+
+**Decision 1 — Bind to `reportingCurrentPhase.phaseYear` (single existing source).**
+Use the already-loaded value rather than re-deriving the year. The header bindings become `Reporting Phase {{ api.dataControlSE.reportingCurrentPhase.phaseYear }}`. Rationale: one source of truth, already correct (2026); avoids the fragility of re-querying.
+
+**Decision 2 — Shared table column made dynamic via the component's API reference.**
+`aow-hlo-table.component.ts` defines the columns array with `'Expected target 2025'`. Build that title from `phaseYear` (e.g., a getter or computed columns reading `this.api.dataControlSE.reportingCurrentPhase.phaseYear`). Because the component is shared by HLO / Intermediate Outcomes / 2030 Outcomes, the single fix covers all three.
+
+**Decision 3 — Guard against a null phase year.**
+`phaseYear` can be null briefly before `getCurrentPhases()` resolves. The binding must degrade gracefully (e.g., show "Reporting Phase" with no trailing year, or wait for the value) rather than render "Reporting Phase null". Confirm the phase is loaded on these routes before relying on it.
+
+## Risks / Trade-offs
+
+- [`phaseYear` null on first paint → "Reporting Phase null"] → guard the binding (omit the year until loaded).
+- [Specs assert the literal "Expected target 2025"] → update the specs to assert the dynamic value with a mocked `reportingCurrentPhase.phaseYear`.
+- [Other hardcoded years exist nearby (indicator-details 2024, baseline 2022-2024)] → explicitly left untouched per scope; documented in the proposal and Jira comment so they are not "accidentally fixed".
+
+## Migration Plan
+
+Pure frontend, no migrations. Deploy with the client build. Rollback = revert the commit.
+
+## Open Questions
+
+- None blocking for the basic scope. The nomenclature/backend items are tracked in the Jira comment tagged to Santi + Ángel.
diff --git a/openspec/changes/p2-3053-dynamic-reporting-phase-year/proposal.md b/openspec/changes/p2-3053-dynamic-reporting-phase-year/proposal.md
new file mode 100644
index 0000000000..ef8d7ac116
--- /dev/null
+++ b/openspec/changes/p2-3053-dynamic-reporting-phase-year/proposal.md
@@ -0,0 +1,36 @@
+## Why
+
+In the Reporting-by-ToC interface (Areas of Work / HLO indicator views) the reporting-phase year is **hardcoded as the literal "2025"** in templates, so after the 2026 phase opened the UI still shows "Reporting Phase 2025" / "Expected target 2025" while 2026 is the active phase. This is the bug reported in **P2-3053** (child of P2-3012, *Open Phase Step 1*), reporter Santiago Sánchez.
+
+The active reporting phase already resolves correctly to 2026 elsewhere via `DataControlService.reportingCurrentPhase.phaseYear` (loaded from `GET_versioning(OPEN, REPORTING)`). The fix binds the hardcoded labels to that value.
+
+**Scope: frontend-only, BASIC only.** Confirmed with Yeck. The broader nomenclature requests in the ticket description (Indicator name → HLO title; KPI statement / typology / targets; entry-point pathway sub-text; the `achieved_in_2024` field which is backend; "all P/A" rollout) are **out of scope** here and have been tagged to Santiago Sánchez + Ángel Jarrín in a Jira comment as clarifications to define separately.
+
+## What Changes
+
+- Replace the hardcoded `Reporting Phase 2025` text with the active phase year (`reportingCurrentPhase.phaseYear`) in:
+ - `entity-aow-aow.component.html` (2 occurrences — High-Level Outputs + Intermediate Outcomes tabs)
+ - `entity-aow-2030.component.html` (1 occurrence — 2030 Outcomes)
+- Make the `aow-hlo-table` column title `Expected target 2025` dynamic (`Expected target {{ phaseYear }}`). This component is shared by all three views, so the fix covers HLO, Intermediate Outcomes and 2030 Outcomes.
+- Replace the 3 hardcoded "2025" mentions in the `aow-hlo-create-modal` description text with the dynamic year.
+- Update the affected unit specs (`aow-hlo-table.component.spec.ts`).
+
+## Capabilities
+
+### New Capabilities
+- `reporting-phase-year-display`: The Reporting-by-ToC views (HLO, Intermediate Outcomes, 2030 Outcomes) display the active reporting-phase year dynamically, never a hardcoded year.
+
+### Modified Capabilities
+- (none)
+
+## Impact
+
+- **Client only** (`onecgiar-pr-client`):
+ - `pages/result-framework-reporting/pages/entity-aow/pages/entity-aow-aow/entity-aow-aow.component.html`
+ - `pages/result-framework-reporting/pages/entity-aow/pages/entity-aow-2030/entity-aow-2030.component.html`
+ - `pages/result-framework-reporting/pages/entity-aow/pages/entity-aow-aow/components/aow-hlo-table/aow-hlo-table.component.ts` (+ `.spec.ts`)
+ - `pages/result-framework-reporting/pages/entity-aow/pages/entity-aow-aow/components/aow-hlo-table/components/aow-hlo-table-create-modal/aow-hlo-create-modal.component.html`
+- **No backend changes.** Year source is the already-loaded `reportingCurrentPhase.phaseYear`.
+- No API contract changes, no migrations.
+- **Explicitly NOT touched:** `outcome-indicator-home.component.html` "2022-2024" (intentional P25 baseline); `indicator-details` "2024" / `achieved_in_2024` (backend field, tagged as separate scope).
+- SDD baseline: fits `docs/system-design/design.md` (Result Framework reporting views). Related ticket: parent P2-3012.
diff --git a/openspec/changes/p2-3053-dynamic-reporting-phase-year/specs/reporting-phase-year-display/spec.md b/openspec/changes/p2-3053-dynamic-reporting-phase-year/specs/reporting-phase-year-display/spec.md
new file mode 100644
index 0000000000..38457380c4
--- /dev/null
+++ b/openspec/changes/p2-3053-dynamic-reporting-phase-year/specs/reporting-phase-year-display/spec.md
@@ -0,0 +1,39 @@
+## ADDED Requirements
+
+### Requirement: Reporting-by-ToC views show the active phase year dynamically
+
+The Reporting-by-ToC views (High-Level Outputs, Intermediate Outcomes, 2030 Outcomes) SHALL display the active reporting-phase year from the application's current-phase state, never a hardcoded year. This applies to the phase header and to the target column title.
+
+#### Scenario: Active phase is 2026
+
+- **WHEN** the active reporting phase is 2026 and a user opens a Reporting-by-ToC view
+- **THEN** the phase header reads "Reporting Phase 2026" and the target column reads "Expected target 2026"
+
+#### Scenario: Phase year changes with the active phase
+
+- **WHEN** the active reporting phase advances to a later year
+- **THEN** the header and target column reflect that year without a code change
+
+#### Scenario: All three views stay consistent
+
+- **WHEN** the active phase year is shown
+- **THEN** High-Level Outputs, Intermediate Outcomes and 2030 Outcomes all display the same active year (the shared table drives the column)
+
+#### Scenario: Phase year not yet loaded
+
+- **WHEN** the active phase year is not yet available (before the current-phase request resolves)
+- **THEN** the header does not render a stray "null" year (it degrades gracefully until the value is loaded)
+
+### Requirement: Reporting-by-ToC entry-point and table labels use the agreed nomenclature
+
+The Reporting-by-ToC entry-point cards and the indicator table headers SHALL use the nomenclature confirmed with the reporter, with the phase year shown dynamically where applicable.
+
+#### Scenario: Entry-point cards
+
+- **WHEN** a user views the Reporting-by-ToC entry point
+- **THEN** the "Theory of Change" card is labeled "Results planned in your {active year} ToC" with a hover tooltip "Report results as planned theory of change", and the "Result Category" card is labeled "Report Emerging results" with a hover info note explaining results that emerged outside the {active year} Theory of Change
+
+#### Scenario: Indicator table headers
+
+- **WHEN** a user views the HLO / Intermediate Outcomes / 2030 Outcomes indicator table
+- **THEN** the column headers read "KPI statement", "Indicator typology", "{active year} target" (dynamic), "Achieved target" and "Status"
diff --git a/openspec/changes/p2-3053-dynamic-reporting-phase-year/tasks.md b/openspec/changes/p2-3053-dynamic-reporting-phase-year/tasks.md
new file mode 100644
index 0000000000..3f9e1ec11c
--- /dev/null
+++ b/openspec/changes/p2-3053-dynamic-reporting-phase-year/tasks.md
@@ -0,0 +1,38 @@
+## 1. Make the phase header dynamic
+
+- [x] 1.1 In `entity-aow-aow.component.html`, replace both `Reporting Phase 2025` with `Reporting Phase {{
}}` (guard against null so it doesn't render "null")
+- [x] 1.2 In `entity-aow-2030.component.html`, replace `Reporting Phase 2025` with the same dynamic binding
+- [x] 1.3 Confirm the components expose the phase year (via `api.dataControlSE.reportingCurrentPhase.phaseYear` or an injected getter); add the accessor if missing
+
+## 2. Make the target column dynamic
+
+- [x] 2.1 In `aow-hlo-table.component.ts`, build the `Expected target ` column title from `reportingCurrentPhase.phaseYear` instead of the literal `'Expected target 2025'` (getter/computed so it updates when the phase loads)
+- [x] 2.2 Confirm the shared component covers all three views (outputs / outcomes / 2030-outcomes) — single change, three views
+
+## 3. Make the modal description dynamic
+
+- [x] 3.1 In `aow-hlo-create-modal.component.html`, replace the 3 hardcoded "2025" mentions in the description with the dynamic phase year
+
+## 4. Tests
+
+- [x] 4.1 Update `aow-hlo-table.component.spec.ts` (asserts `'Expected target 2025'`) to mock `reportingCurrentPhase.phaseYear` and assert the dynamic title
+- [x] 4.2 Add/adjust a test that the header/column reflect the mocked active year, and that a null year degrades gracefully
+- [x] 4.3 Run the affected specs; ensure green
+
+## 6. Entry-point cards (clarified by Santi 2026-06-22)
+
+- [x] 6.1 In `entity-details.component.html`, card "Reporting by Theory of Change" → label "Results planned in your {{ year }} ToC" (dynamic year) + a question-circle tooltip "Report results as planned theory of change"
+- [x] 6.2 Card "Reporting by Result Category" → label "Report Emerging results" + a question-circle info note (hover) "Report achievements that were not originally included in the {{ year }} Theory of Change, but emerged as valuable results during the year."
+- [x] 6.3 Ensure TooltipModule is available in the component; use `pi pi-question-circle` + `pTooltip`
+
+## 7. Table header renames (clarified by Santi)
+
+- [x] 7.1 In `aow-hlo-table.component.ts` columnOrder: Indicator name → "KPI statement"; Type → "Indicator typology"; "Expected target {year}" → "{year} target" (keep dynamic); Actual achieved → "Achieved target"; Status unchanged
+- [x] 7.2 Update `aow-hlo-table.component.spec.ts` assertions for the renamed headers
+
+## 5. Verify & guardrails
+
+- [x] 5.1 Build/compile clean (template bindings valid)
+- [x] 5.2 Confirm NOT touched: `indicator-details` "2024"/`achieved_in_2024`, `outcome-indicator-home` "2022-2024" baseline
+- [x] 5.3 grep the result-framework-reporting views to confirm no remaining hardcoded "Reporting Phase 2025" / "Expected target 2025"
+- [ ] 5.4 Manual check if possible (or note pending: needs login)