CCN Template Skeleton

This file is a placeholder-tokenised skeleton used by the documentation-bc-ccn-generator skill. Section headings, ordering, frontmatter keys, §1 Header field labels, table column headers, diagram marker attributes, and the verdict tokens (GO / CONDITIONAL-GO / NO-GO) are byte-stable and always in canonical English so the downstream md-to-docx-converter Word template and JSON extraction keys bind identically regardless of the target content language.

Translation rule: when the skill is invoked with language ≠ en, translate ONLY the natural-language content — prose paragraphs, list-item text, table cell values, the leading blockquote under the H1, SWOT body text, risk descriptions / mitigations, advisories, and free-text §1 values such as Client. Do NOT translate: H1/H2/H3 headings, YAML keys, §1 field labels, table column headers, diagram markers, identifier values (CCN-NNN, US-NNN, SPEC-NNN, ARCH-NNN, ANALYSIS-NNN), dates, version numbers, enum values (Pending Approval), or the verdict token in §9.

Section-key anchors: every H2 in this skeleton is immediately followed by an HTML-comment anchor of the form . These anchors are byte-stable, language-neutral, CCN-number-neutral and are the contract between this skill and the md-to-docx-converter. They map each section to a fixed placeholder key ({{Header}}, {{BusinessContext}}, {{ProposedSolution}}, {{Architecture}}, {{FeasibilityAnalysis}}, {{TimeEstimate}}, {{TestingSetup}}, {{TestingSteps}}, {{Recommendation}}, {{Approvals}}) inside the Word template, regardless of the visible H2 text or content language. Keep the anchors verbatim — do NOT translate, renumber, or remove them.

Replace every <...> token. Drop any frontmatter line or section paragraph marked (optional — include only if …) when its source artefact is absent or the interview answer excludes it.

---
id: CCN-<NNN>
title: Change Control Note — <Title>
version: 1.0
status: Pending Approval
client: <Client>
dsd_ticket: TBD
user_story: US-<NNN>
spec: SPEC-<NNN>
architecture: ARCH-<NNN>          # (optional — include only if ARCH exists)
analysis: ANALYSIS-<NNN>          # (optional — include only if ANALYSIS exists)
prepared_by: <Author>
date: <YYYY-MM-DD>
recommendation: <GO | CONDITIONAL-GO | NO-GO>
related_docs:
  - openspec/userstories/US-<NNN>-<kebab>.story.md
  - openspec/specs/SPEC-<NNN>-<kebab>.spec.md
  # - openspec/architecture/ARCH-<NNN>-<kebab>.architecture.md   (optional)
  # - openspec/analysis/ANALYSIS-<NNN>-<kebab>.analysis.md       (optional)
template: 5_CCN_Template.docx
language: en
---

CCN- —

Formal change-control note for the <Title> module to be delivered inside the <extension-name> Business Central extension for . This document consolidates the approved user story (US-), the technical specification (SPEC-), the architecture rationale (ARCH-), and the feasibility analysis (ANALYSIS-) into a single stakeholder-facing artefact. <One-line statement: which monetary / hour data is included or excluded, echoing the interview answer.>

§1 field labels MUST be bold-wrapped so the downstream metadata extractor (md-to-docx-converter) recognises them. Values MUST be plain text — no markdown links inside the table cells, no backticks, no em-dashes, no Spanish accents on labels.

Field	Value
CCN ID	CCN-
Title
Client
DSD ticket	TBD
BC environment	<On-premises / SaaS / both>
BC version baseline	<BC X.Y (runtime Z.W)>
Extension affected	(publisher , prefix , id range )
Source user story	US- (approved )
Source spec	SPEC- (approved )
Architecture	ARCH-
Analysis	ANALYSIS-
Prepared by
Date
Status	Pending Approval
Recommendation	<GO / CONDITIONAL-GO / NO-GO>

Business context

Drawn from US-.

2.1 Who

2.2 What they want

<One-paragraph "I want …" restatement>

2.3 Why

<One-paragraph "so that …" restatement>

2.4 Objective

2.5 Functional scope

<bullet 1>
<bullet 2> …

2.6 Acceptance criteria (US- summary)

#	Topic
AC01
…	…

2.7 Out of scope (Phase 1)

2.8 Future enhancements (noted)

Proposed solution

Drawn from SPEC-.

3.1 Design principles

<principle 1>
<principle 2> …

3.2 AL object inventory

Type	ID	Name	Purpose
<Table/Enum/Page/PageExt/Codeunit/PermSet>

Totals: <N new objects, M modified AL objects, K modified translation files>.

3.3 Number series

3.4 API surface

3.5 Localisation

3.6 Open-question resolutions (US-)

3.7 Delivery in phases

Phase	Scope
1
2
…	…

Open → In Progress → Pending Review → Appealed → Closed (+ explicit Reopen)

stateDiagram-v2
    [*] --> Open
    Open --> InProgress
    InProgress --> PendingReview
    PendingReview --> Appealed
    Appealed --> Closed
    Closed --> Open : Reopen
    Closed --> [*]

Architecture solution

Drawn from ARCH-.

(If ARCH not yet available, replace this whole section with: "Architecture document not yet available — section derived from SPEC only.")

4.1 Architecture Decision Records (summary)

ADR	Decision	Why
ADR-1
…	…	…

4.2 Logical component view

<ASCII component view copied verbatim from ARCH §4.2 — optional, for human readers only>

flowchart TD
    %% Author the Mermaid component view here — mirror the boxes / arrows from ARCH §4.2.
    UI[UI layer] --> Domain[Domain / facade]
    Domain --> Data[Data layer]
    Data --> Standard[Standard BC plumbing]

4.3 Cross-cutting concerns

Concern	Approach
Security	<…>
Reliability	<…>
Performance	<…>
Observability	<…>
Localisation	<…>
RapidStart / portability	<…>
Upgrade / migration	<…>

4.4 Coexistence with legacy code

4.5 Known constraints

#	Constraint	Mitigation
C-1
…	…	…

<ASCII ER / table relations copied verbatim from ARCH §6.1 — optional, for human readers only>

erDiagram
    %% Author the Mermaid ER here — omit this whole marker block if ARCH has no ER.
    PARENT ||--o{ CHILD : has

<ASCII runtime flow copied verbatim from ARCH §5 — optional, for human readers only>

sequenceDiagram
    %% Author the Mermaid sequence flow here — repeat the whole marker block once per flow.
    actor User
    User->>System: action
    System-->>User: response

Feasibility analysis

Drawn from ANALYSIS-.

(If ANALYSIS not yet available, replace this whole section with: "Feasibility analysis not yet available — §5 and §6 are intentionally omitted.")

5.1 Change summary

5.2 SWOT

Strengths —

Weaknesses —

Opportunities —

Threats —

5.3 Risk register

#	Risk	Likelihood	Impact	Mitigation
R-01		<Low/Medium/High>	<Low/Medium/High>
…	…	…	…	…

Overall risk rating: <LOW | LOW–MEDIUM | MEDIUM | MEDIUM–HIGH | HIGH>.

5.4 Open-question status

Time estimate

Rendering depends on the interview answers:

include_hours = no → replace this entire section with: _Effort and duration intentionally omitted from this version of the document._

include_hours = yes, include_costs = no → render §6.1 and §6.2 only; strip any EUR columns.

include_hours = yes, include_costs = yes → render §6.1, §6.2, and §6.3 (Cost). State the EUR/h rate verbatim from ANALYSIS.

One column per selected scenario in scenarios (Optimistic / Expected / Pessimistic / Neutral).

6.1 Effort per phase

Phase	Scope	<Scenario 1> (h)	<Scenario 2> (h)
1
…	…	…	…
—	Base subtotal
—	Contingency (<%> across phases)	+	+
—	Total	≈	≈

6.2 Calendar duration

Item	<Scenario 1>	<Scenario 2>
Development working days
Review working days
Total working days
Wall-clock duration	≈	≈

6.3 Cost

(Only when include_costs = yes.)

Rate: EUR / hour (verbatim from ANALYSIS).

Scenario	Total hours	Total cost (EUR)
<Scenario 1>
<Scenario 2>
…	…	…

6.4 Assumptions

Testing setup (planned)

Phase	Test coverage
1
…	…

Each phase exits only when its dedicated test codeunit (where applicable) is green and the manual smoke checklist is signed off.

Testing steps (acceptance, executed by )

…

Recommendation

<GO | CONDITIONAL-GO | NO-GO>

Non-blocking advisories at kick-off

<advisory 1>
<advisory 2> …

(If verdict = CONDITIONAL-GO, insert ### Pre-conditions numbered list above the advisories.)

Approvals

Role	Name	Decision	Date	Signature
— Product Owner	—	☐ Approved · ☐ Rejected · ☐ Changes requested	—	—
— Technical Lead	—	☐ Approved · ☐ Rejected · ☐ Changes requested	—	—
— Project Manager	—	☐ Approved · ☐ Rejected · ☐ Changes requested	—	—

Once all three approvals are recorded, the Architect may flip the phase plans in openspec/plans/ from not-started to approved and hand off Phase 1 to the AL Developer.

Header​

Business context​

2.1 Who​

2.2 What they want​

2.3 Why​

2.4 Objective​

2.5 Functional scope​

2.6 Acceptance criteria (US- summary)​

2.7 Out of scope (Phase 1)​

2.8 Future enhancements (noted)​

Proposed solution​

3.1 Design principles​

3.2 AL object inventory​

3.3 Number series​

3.4 API surface​

3.5 Localisation​

3.6 Open-question resolutions (US-)​

3.7 Delivery in phases​

Architecture solution​

4.1 Architecture Decision Records (summary)​

4.2 Logical component view​

4.3 Cross-cutting concerns​

4.4 Coexistence with legacy code​

4.5 Known constraints​

Feasibility analysis​

5.1 Change summary​

5.2 SWOT​

5.3 Risk register​

5.4 Open-question status​

Time estimate​

6.1 Effort per phase​

6.2 Calendar duration​

6.3 Cost​

6.4 Assumptions​

Testing setup (planned)​

Testing steps (acceptance, executed by )​

Recommendation​

<GO | CONDITIONAL-GO | NO-GO>​

Non-blocking advisories at kick-off​

Approvals​

Header