arckit-cli 6.1.1__py3-none-any.whl

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/ca-soia.md

@@ -0,0 +1,87 @@
+# Canada Security of Information Act Handling Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:ca-soia` generates a Canada *Security of Information Act* (SOIA) handling plan for a federal information system that processes Special Operational Information (SOI) or other classified material. The artefact captures the SOI inventory under the s.8 statutory definition, the marking and handling matrix, the transmission-channel matrix, the compartment and need-to-know register, destruction and sanitisation routes, the CSIS Act §16 / §19 coordination map, the RCMP National Security Programme liaison points, the breach-response runbook, and the personnel-reliability envelope.
+
+SOIA handling sits on top of the ITSG-33 security baseline. The ITSG-33 Statement of Applicability fixes the categorisation, the control profile, and the cryptographic envelope; the SOIA plan layers the statutory handling rules — compartmentation, the Third-Party Rule for foreign-shared product, and the breach-response timing that distinguishes SOI from material that is merely classified. Run `ca-itsg-33` first; the SOIA artefact reads its categorisation as a prerequisite. Note that the SOIA plan itself will frequently warrant a SECRET or higher classification — store, mark, and handle the artefact accordingly.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | Functional context and the SOI-relevant data flows |
+| ITSG-33 Statement of Applicability (`ARC-<id>-ITSG-v1.0.md`) | System-level categorisation, control profile, and CMVP envelope — prerequisite |
+| FITAA Compliance Assessment (`ARC-<id>-FITAA-v1.0.md`) | Where present, the protected investigative dataset overlaps with SOI |
+| Privacy Impact Assessment (`ARC-<id>-PIA-v1.0.md`) | Personal-information drivers for any identities subject to s.8 protection |
+
+---
+
+## Command
+
+```bash
+/arckit:ca-soia <project ID or service description>
+```
+
+Output: `projects/<id>/ARC-<id>-SOIA-v1.0.md`
+
+---
+
+## Assessment Structure
+
+| Section | Contents |
+|---------|----------|
+| Document Control | Canadian classification (UNCLASSIFIED / Protected A–C / CONFIDENTIAL / SECRET / TOP SECRET) — note the artefact itself is likely classified |
+| Revision History | Version, date, author, changes, approvals |
+| Executive Summary | SOI scope, highest classification handled, compartment count, breach-response posture |
+| SOI Inventory | Per-asset s.8 categorisation with originator and stewardship |
+| Marking Matrix | Classification, caveats (CEO / NOFORN / FVEY), compartments, releasability |
+| Handling Rules | At rest, in transit, in use — tiered per classification level |
+| Transmission Channel Matrix | Allowed / Not Allowed per classification × channel with caveat footnotes |
+| Compartment / Need-to-Know Register | Owners, access-list size, audit cadence, indoctrination |
+| Destruction and Sanitisation | Per-media-class methods anchored on CSE ITSP.40.006 |
+| CSIS Act §16 / §19 Coordination | System role, coordinating contacts, artefacts |
+| RCMP NSP Liaison | INSET / SI&IS / Federal Policing triggers and contacts |
+| Breach Response Runbook | Timed runbook from minutes-to-30-days plus severity escalation table |
+| Personnel Reliability | Per-role clearance, cycle, briefing, indoctrination |
+| Open Items | Statutory-currency caveats, pending MOUs, indoctrination backlog |
+| External References | Document Register, Citations, Unreferenced |
+
+---
+
+## When to run
+
+- Any system that processes SOI or other classified material — the SOIA plan is mandatory before the system handles its first SOI artefact.
+- Vendor-managed services touching classified material — the supplier-side handling rules must be designed before the contract authorises classified processing.
+- Pre-authorisation for any TOP SECRET system — the authorising official will not grant Authority to Operate without a SOIA handling plan.
+- Significant change to the compartment design — adding a compartment, dissolving a compartment, expanding the access list beyond a baseline threshold, or changing the indoctrination requirement.
+
+---
+
+## Common pitfalls
+
+- **Treating compartmentation as a label rather than a control.** Compartmentation defaults to deny; every access decision is an explicit need-to-know determination. A compartment with a stale access list, no audit cadence, or default-allow indoctrination is functionally a non-compartment, and the auditor will say so.
+- **Third-Party Rule violations on foreign-shared product.** CANADIAN EYES ONLY, NOFORN, and FVEY-restricted material can only be redistributed with the originator's consent. Routing CEO product over allied-shared infrastructure, or onward-sharing FVEY material to a non-FVEY recipient without consent, is a reportable breach.
+- **Clearance-by-role rather than clearance-per-task.** A SECRET clearance authorises the holder to access SECRET material on a need-to-know basis; it does not authorise access to every SECRET system in the department. Build the access list per task, not per role title.
+- **Under-defining breach-response timing.** Initial containment must occur within minutes — revoke access, isolate the system, suspend the account. Waiting for forensic completeness before containment is the second-highest-impact failure mode after default-allow on a compartment.
+- **Conflating SOIA with the *Access to Information Act* §15 exemption analysis.** SOIA governs how SOI is created, marked, transmitted, stored, and destroyed across its lifecycle; ATIP §15 (international affairs and defence) and §16 (law enforcement) govern whether SOI is *disclosed* in response to an access request. They are different regimes with different decision-makers; the SOIA plan does not pre-empt the ATIP severance review, and vice versa.
+
+---
+
+## Handoffs
+
+- **`ca-itsg-33`** — SOIA handling rules sit on top of the ITSG-33 security baseline. Categorisation and control profile are the prerequisite layer; run `ca-itsg-33` first so the SOIA plan can read the system-level categorisation as an input rather than re-deriving it.
+- **`risk`** — SOIA-specific residual risks (compartment compromise, suspected unauthorised disclosure, supplier-side mishandling, compartment-MOU expiry) flow into the operational risk register. Carry the risk IDs forward so the residual posture is traceable in the same register as the ITSG-33 residuals.
+- **`adr`** — Compartment design, MOU choices with CSIS or RCMP, and tier-promotion thresholds (when does a Protected C system promote to SECRET because the SOI envelope has expanded) warrant Architecture Decision Records. The SOIA plan captures the rule; the ADR captures the architectural rationale and the alternatives considered.
+
+---
+
+## Statutory currency
+
+The *Security of Information Act* itself is comparatively stable, but the surrounding statutory envelope is not. CSIS Act amendments via Bill C-26 (cyber security) and Bill C-70 (foreign interference) are still settling, and Ministerial Directives shape § 16 collection and § 19 disclosure practice on shorter cycles than the Act. Cite the consolidated Justice Laws Website text and record the verification date in the External References section so a reviewer can audit currency.
+
+---
+
+The artefact produced by `/arckit:ca-soia` is itself often classified. Apply the same marking, storage, and handling rules to the plan as to the SOI it describes — store in a TBS-approved system, mark per the classification line in the Document Control header, and treat its distribution as a compartment access decision under the same need-to-know rules captured inside it.

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/codes-of-practice.md

@@ -0,0 +1,154 @@
+# UK Government Codes of Practice — ArcKit Reference Guide
+
+> **Guide Origin**: Official | **ArcKit Version**: [VERSION]
+
+This guide maps HM Treasury and Cabinet Office codes of practice to ArcKit commands and artefacts. These publications — informally known as the "Rainbow of Books" — set expectations for evaluation, analytical quality, knowledge asset management, and commercial procurement across government.
+
+---
+
+## The Rainbow of Books
+
+| Book | Publisher | Purpose | ArcKit Coverage |
+|------|-----------|---------|-----------------|
+| **Green Book** | HM Treasury | Appraisal and evaluation of policies, programmes, and projects | `/arckit:sobc` (5-case model), `/arckit:finops` |
+| **Orange Book** | HM Treasury | Risk management principles and concepts | `/arckit:risk` (risk register) |
+| **Magenta Book** | HM Treasury | Evaluation design — scoping, designing, and conducting evaluations | `/arckit:sobc` (benefits realisation), `/arckit:plan` |
+| **AQuA Book** | HM Treasury / Analysis Function | Analytical quality assurance — producing robust analysis | `/arckit:analyze`, `/arckit:data-model` |
+| **Rose Book** | GOTT | Knowledge asset management — identifying, protecting, and exploiting IP | `/arckit:strategy`, `/arckit:principles`, `/arckit:data-model` |
+
+### Commercial Playbooks
+
+| Playbook | Publisher | Purpose | ArcKit Coverage |
+|----------|-----------|---------|-----------------|
+| **Sourcing Playbook** | Cabinet Office | Procurement strategy, market assessment, should-cost modelling | `/arckit:dos`, `/arckit:sow`, `/arckit:evaluate` |
+| **Consultancy Playbook** | Cabinet Office | When to use consultants, knowledge transfer, value for money | `/arckit:sow`, `/arckit:research` |
+| **DDaT Playbook** | Cabinet Office | Digital procurement policy reforms, open standards, interoperability | `/arckit:dos`, `/arckit:tcop` |
+
+---
+
+## Magenta Book — Evaluation Design
+
+The [Magenta Book](https://www.gov.uk/government/publications/the-magenta-book) provides guidance on designing and conducting evaluations of government policies and programmes.
+
+### Key Concepts
+
+| Concept | Description | ArcKit Artefact |
+|---------|-------------|-----------------|
+| **Theory of Change** | Logic model linking inputs → activities → outputs → outcomes → impact | `/arckit:sobc` (Strategic Case, benefits chain) |
+| **Proportionality** | Match evaluation effort to spend, risk, and novelty | `/arckit:sobc` (Management Case) |
+| **Process evaluation** | Assess how a programme is being implemented | `/arckit:service-assessment` |
+| **Impact evaluation** | Assess whether the programme caused observed outcomes | `/arckit:sobc` (benefits realisation) |
+| **Value-for-money evaluation** | Assess efficiency and cost-effectiveness | `/arckit:finops`, `/arckit:sobc` (Economic Case) |
+
+### When to Apply
+
+- **Discovery/Alpha**: Define evaluation questions and Theory of Change
+- **Beta**: Establish baseline data and process evaluation
+- **Live**: Conduct impact and value-for-money evaluations
+- **Post-implementation**: Benefits realisation review
+
+---
+
+## AQuA Book — Analytical Quality Assurance
+
+The [AQuA Book](https://www.gov.uk/guidance/the-aqua-book) provides guidance on producing quality analysis for government. It defines an analytical lifecycle and quality assurance roles.
+
+### Analytical Lifecycle
+
+| Stage | Description | ArcKit Artefact |
+|-------|-------------|-----------------|
+| **Scope** | Define the question and analytical approach | `/arckit:requirements` (analytical requirements) |
+| **Design** | Select methods, data sources, assumptions | `/arckit:data-model` (data sources, quality) |
+| **Conduct** | Perform the analysis | `/arckit:analyze` |
+| **Communicate** | Present findings clearly with caveats | `/arckit:analyze` (output document) |
+| **Review** | Independent assurance of the analysis | `/arckit:hld-review` (peer review pattern) |
+
+### QA Roles
+
+| Role | Responsibility |
+|------|---------------|
+| **Commissioner** | Defines the question and approves the approach |
+| **Analyst** | Conducts the analysis and documents methodology |
+| **Analytical Assurer** | Independent review of quality and fitness for purpose |
+
+### Verification vs Validation
+
+- **Verification**: Is the analysis error-free? (correct calculations, code, data handling)
+- **Validation**: Is the analysis fit for purpose? (answers the right question, appropriate method)
+
+---
+
+## Rose Book — Knowledge Asset Management
+
+The [Rose Book](https://www.gov.uk/government/publications/knowledge-asset-management-in-government) (v2, March 2024) provides guidance on identifying, valuing, and managing knowledge assets in government.
+
+### Five Knowledge Asset Categories
+
+| Category | Examples | ArcKit Touch Point |
+|----------|---------|-------------------|
+| **Research** | Publications, datasets, methodologies | `/arckit:data-model` (data assets) |
+| **Data** | Databases, registers, statistical collections | `/arckit:data-model`, `/arckit:data-mesh-contract` |
+| **Content** | Digital services, websites, apps | `/arckit:strategy` (digital assets) |
+| **Software** | Code, algorithms, AI models | `/arckit:principles` (open source policy) |
+| **IP / Know-how** | Patents, trademarks, trade secrets, expertise | `/arckit:principles` (IP/reuse principles) |
+
+### Knowledge Asset Register
+
+Projects creating significant knowledge assets should maintain a register covering:
+
+- Asset description and category
+- Owner and steward
+- IP protection status (patent, copyright, open source)
+- Valuation approach (market-based, cost-based, income-based)
+- Exploitation pathway (licensing, spin-out, open publication, partnership)
+- Reuse potential for other government departments
+
+---
+
+## Commercial Playbooks — Procurement
+
+The [Sourcing and Consultancy Playbooks](https://www.gov.uk/government/publications/the-sourcing-and-consultancy-playbooks) set expectations for government procurement.
+
+### Sourcing Playbook Key Actions
+
+| Action | Description | ArcKit Artefact |
+|--------|-------------|-----------------|
+| **Market assessment** | Understand the supplier landscape and capability | `/arckit:research` (market research) |
+| **Should-cost modelling** | Estimate realistic costs before procurement | `/arckit:sobc` (Financial Case) |
+| **Outcome-based specs** | Define what, not how — focus on outcomes | `/arckit:dos` (outcome description), `/arckit:sow` |
+| **Social value** | Minimum 10% weighting in evaluation | `/arckit:evaluate` (evaluation criteria) |
+| **SME access** | Ensure opportunities are accessible to SMEs | `/arckit:dos` (lot structure) |
+| **KPIs and contract management** | Define measurable performance indicators | `/arckit:sow` (SLA and acceptance criteria) |
+
+### DDaT Playbook Policy Reforms
+
+| Reform | Description | ArcKit Artefact |
+|--------|-------------|-----------------|
+| **Open standards** | Use open data and interface standards | `/arckit:principles`, `/arckit:tcop` |
+| **Interoperability** | Avoid lock-in, ensure portability | `/arckit:hld-review` |
+| **Modular contracting** | Break large programmes into smaller contracts | `/arckit:dos` (lot structure) |
+| **User-centred** | Procurement driven by user needs | `/arckit:requirements`, `/arckit:service-assessment` |
+
+---
+
+## Delivery Lifecycle Mapping
+
+| Phase | Applicable Books | Key ArcKit Commands |
+|-------|-----------------|---------------------|
+| **Strategy & Discovery** | Green Book, Magenta Book (evaluation questions), Sourcing Playbook (market assessment) | `/arckit:sobc`, `/arckit:research`, `/arckit:stakeholders` |
+| **Alpha** | AQuA Book (analytical design), Rose Book (asset identification), DDaT Playbook | `/arckit:analyze`, `/arckit:principles`, `/arckit:dos` |
+| **Beta** | Magenta Book (baseline data), AQuA Book (QA review), Sourcing Playbook (procurement) | `/arckit:evaluate`, `/arckit:sow`, `/arckit:data-model` |
+| **Live** | Magenta Book (impact evaluation), Orange Book (ongoing risk), Commercial Playbooks (contract management) | `/arckit:finops`, `/arckit:risk`, `/arckit:operationalize` |
+| **Post-implementation** | Green Book (benefits review), Magenta Book (VfM evaluation), Rose Book (exploitation) | `/arckit:sobc` (benefits realisation), `/arckit:strategy` |
+
+---
+
+## References
+
+- [HM Treasury Green Book](https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-government)
+- [HM Treasury Orange Book](https://www.gov.uk/government/publications/orange-book)
+- [HM Treasury Magenta Book](https://www.gov.uk/government/publications/the-magenta-book)
+- [AQuA Book](https://www.gov.uk/guidance/the-aqua-book)
+- [Rose Book (Knowledge Asset Management)](https://www.gov.uk/government/publications/knowledge-asset-management-in-government)
+- [Sourcing and Consultancy Playbooks](https://www.gov.uk/government/publications/the-sourcing-and-consultancy-playbooks)
+- [Government Functional Standards](https://www.gov.uk/government/collections/functional-standards)

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/competitors.md

@@ -0,0 +1,202 @@
+# Competitor Landscape Guide
+
+> **Guide Origin**: Official | **ArcKit Version**: [VERSION]
+
+`/arckit:competitors` discovers competitor landscape intelligence — rival suppliers, awarded-value market share, head-to-head comparison, and concentration — from live UK procurement notices via the UK Tenders MCP.
+
+> **Agent Architecture**: This command uses a three-tier reader/writer subagent split. The **`arckit-tenders-reader`** subagent fetches evidence from the UK Tenders MCP (shared with `/arckit:tenders`, keeping that I/O isolated from your main context window). The orchestrator tier (the slash command) validates the reader's JSON payload against the `tenders-handoff.schema.json` schema and computes deterministic derived fields, including the supplier-rivalry head-to-head. The **`arckit-competitors-writer`** subagent then renders the final artefact. The slash command launches and coordinates both agents.
+
+---
+
+## What is Competitor Landscape Intelligence?
+
+Competitor landscape intelligence is the systematic analysis of real awarded-contract data to understand who else is winning work in a capability space — their share of awarded value, which buyers they serve, and how a focal supplier compares against each rival.
+
+**Key questions answered:**
+
+- Who are the rival suppliers in this capability space, and what is their awarded-value share?
+- How does a named supplier compare against each rival (shared buyers, recent wins)?
+- How concentrated is the competitive landscape — is one supplier dominant?
+- Which government buyers are active in this space?
+
+> **Mandatory caveat.** Awarded value is not actual spend; figures are for market context and benchmarking, not the costed Economic Case. Never use CMPT figures as the cost line in a Green Book / Orange Book Economic Case without independent substantiation.
+
+---
+
+## When to Use
+
+- **Before a vendor evaluation** — understand who has already won similar work and at what scale
+- **Before scoping a competition** — know the realistic supplier pool and whether concentration is a risk
+- **When building a Company Experience scorecard** — rival award history provides comparative context for `/arckit:score`
+- **When assessing a sole-source or incumbent renewal** — evidence the broader competitive landscape
+- **As part of a build-vs-buy analysis** — quantify the commercial supply depth alongside `/arckit:research`
+
+---
+
+## Prerequisites and Dependencies
+
+| Artefact | Dependency | Why |
+|----------|-----------|-----|
+| Requirements (`ARC-*-REQ-*.md`) | OPTIONAL | Capability keywords and CPV codes can be derived from DR/FR/INT requirements |
+| Architecture Principles (`ARC-000-PRIN-*.md`) | OPTIONAL | Identifies the organisational context for capability scoping |
+| Vendor Profiles (`vendors/{slug}-profile.md`) | ENRICHED | Pre-existing vendor profiles gain an enriched Government Award History section |
+| Risk Register (`ARC-*-RISK-*.md`) | DOWNSTREAM | Supplier-concentration findings feed R-xxx concentration/single-supplier-dependency risks |
+
+---
+
+## Inputs
+
+The command accepts three input forms, which can be combined:
+
+| Input | Flag / Form | Example |
+|-------|-------------|---------|
+| Supplier focus (focal supplier) | `--supplier 'Name'` | `/arckit:competitors --supplier 'Acme Cloud Ltd'` |
+| Capability (free text) | bare arguments | `/arckit:competitors cloud hosting` |
+| CPV code | `--cpv NNNNNNNN` | `/arckit:competitors --cpv 72200000` |
+
+Use `--supplier 'Name'` to run a **supplier-focus** query: the named supplier becomes the focal point and the command produces a head-to-head comparison against each rival. Without `--supplier`, the command runs in **capability-focus** mode: it returns the full competitive set ranked by awarded-value share, with no focal supplier or head-to-head.
+
+You can combine flags: `/arckit:competitors cloud hosting --cpv 72200000 --supplier 'Acme Cloud Ltd'`.
+
+**CPV code format:** eight digits, optionally followed by a division suffix (`NNNNNNNN-N`). Common codes:
+
+| Code | Category |
+|------|----------|
+| 72200000 | Software-related services |
+| 72300000 | Data services |
+| 72600000 | IT support and consultancy |
+| 48000000 | Software packages and systems |
+| 79000000 | Business services |
+| 73000000 | R&D services |
+
+---
+
+## Scenario Matrix
+
+| Scenario | Prompt | Focus |
+|---------|--------|-------|
+| Capability landscape | `/arckit:competitors digital identity verification` | Rival suppliers ranked by awarded-value share |
+| Supplier head-to-head | `/arckit:competitors --supplier 'Acme Cloud Ltd'` | Focal supplier vs each rival |
+| Scoped supplier analysis | `/arckit:competitors --cpv 72600000 --supplier 'Acme Cloud Ltd'` | Focal supplier vs rivals in a specific CPV |
+| Market concentration check | `/arckit:competitors cloud hosting --cpv 72200000` | Concentration flag and supply-base depth |
+| Vendor evaluation context | `/arckit:competitors managed security operations` | Who is winning, at what value, for which buyers |
+
+---
+
+## Command
+
+```bash
+/arckit:competitors [project-number-or-name] <--supplier 'Name' | capability | --cpv NNNNNNNN>
+```
+
+Outputs: `projects/<id>/research/ARC-<id>-CMPT-<NNN>-v1.0.md`
+
+> **Multi-instance type**: `CMPT` artefacts are sequenced within the project's `research/` directory. Re-running produces a new numbered artefact (`CMPT-001`, `CMPT-002`, …) rather than overwriting the previous run.
+
+---
+
+## Long runs: Remote Control + push notifications
+
+`/arckit:competitors` can take several minutes when the UK Tenders MCP needs to page through large result sets. To avoid babysitting the terminal, pair it with [Claude Code Remote Control](https://code.claude.com/docs/en/remote-control):
+
+```bash
+claude remote-control
+```
+
+Drive the session from claude.ai/code or the mobile app, then enable `/config → Push when Claude decides` so your phone gets a notification on completion. ArcKit's minimum Claude Code floor (v2.1.121) already covers the v2.1.110 RC requirement.
+
+Caveats: Pro/Max plans only (no API keys, no Bedrock/Vertex/Foundry), push is a single on/off so chatty agents can over-notify, and the local `claude` process must keep running.
+
+---
+
+## Artefact Sections
+
+A completed CMPT artefact contains:
+
+1. **Executive Summary** — 3–5 key findings, concentration flag, focal supplier position (supplier-focus runs only).
+2. **Query Scope** — recorded focus, CPV, supplier, keywords, date range so the run is reproducible.
+3. **Competitive Set** — rival suppliers ranked by awarded-value share %, with award counts and key buyers.
+4. **Focal Supplier** — on supplier-focus runs, the named supplier's awarded value, award count, and share pulled out of the competitive set.
+5. **Head-to-Head** — on supplier-focus runs, the focal supplier compared against each rival: shared buyers, rival's most recent win. Renders not-applicable on capability-focus runs.
+6. **Per-Rival Buyer Relationships and Recent Wins** — short prose per rival derived from the data.
+7. **Concentration** — top-1 / top-3 share and a `HIGH` / `MEDIUM` / `LOW` flag with the rule applied.
+8. **Representative Notices** — sample award notices with their `notice_url` (required for OGL attribution).
+9. **Data Freshness and Source Health** — `Data current as of <ISO datetime>` or a freshness-unavailable note when the status endpoint was unreachable.
+10. **Caveats** — including the mandatory awarded-value caveat.
+
+### Concentration Flag Rules
+
+| Flag | Condition |
+|------|-----------|
+| `HIGH` | Top-1 supplier share > 50% **or** top-3 supplier share > 80% |
+| `MEDIUM` | Top-3 supplier share > 60% (and HIGH conditions not met) |
+| `LOW` | All other cases |
+
+A `HIGH` concentration flag should be registered as a supplier-dependency risk in the project Risk Register (`/arckit:risk`).
+
+---
+
+## Vendor Profile Enrichment
+
+When a project already has a vendor profile (`vendors/{slug}-profile.md`) for a rival supplier, the `arckit-competitors-writer` subagent enriches that profile's **Government Award History** section with the award data from the competitive set. This means running `/arckit:competitors` before `/arckit:score` gives the score command richer comparative evidence to work with.
+
+The writer performs a bounded section-merge — it updates only the `## Government Award History` section of pre-existing profiles. It does **not** create new profile files.
+
+---
+
+## Data Source
+
+| Property | Detail |
+|----------|--------|
+| **MCP server** | `uk-tenders` (keyless, deferred load, shared with `/arckit:tenders`) |
+| **Coverage** | ~677,000 UK contracting processes across five national portals |
+| **Portals covered** | Find a Tender Service (FTS), Contracts Finder, Public Contracts Scotland, Sell2Wales, eTendersNI |
+| **Refresh cadence** | Nightly |
+| **Availability** | Best-effort single Cloud Run instance — no formal SLA. A dead endpoint degrades gracefully (the reader returns partial data and the artefact renders with degraded-source notes). |
+| **Licence** | Open Government Licence v3.0 (OGL v3.0) |
+| **Attribution** | Every notice record carries its official `notice_url`; artefacts must include the OGL v3.0 attribution line |
+
+### OGL Attribution
+
+Every CMPT artefact includes the attribution line:
+
+> Contains public sector information licensed under the Open Government Licence v3.0.
+
+The source data is re-published by the UK Tenders MCP from official UK procurement portals verbatim under the OGL v3.0. Every supplier figure and share percentage in the artefact traces to a `notice_url` citation from the relevant portal.
+
+---
+
+## Evaluation Criteria Explained
+
+The reader returns evidence across five procurement portals, ranked internally by:
+
+| Criterion | Purpose |
+|-----------|---------|
+| **Awarded value** | Primary ranking signal for rivals and share calculations |
+| **Award count** | Proxy for market depth (many small awards vs few large awards) |
+| **Share %** | Concentration measurement; feeds the top-1 / top-3 concentration flag |
+| **Date range coverage** | Assesses recency and whether the competitive landscape has changed materially |
+| **Source health** | Flags which portal feeds were degraded at fetch time |
+
+---
+
+## Integration with Other Commands
+
+| Direction | Command | Integration |
+|-----------|---------|-------------|
+| **Input** | `/arckit:requirements` | CPV codes and capability keywords derived from DR/FR/INT |
+| **Input** | `/arckit:tenders` | TNDR artefact narrows the capability scope and provides market benchmarks |
+| **Output** | `/arckit:research` | Feed the competitive set into build-vs-buy analysis and TCO comparison |
+| **Output** | `/arckit:score` | Rival award history used as comparative Company Experience evidence |
+| **Output** | `/arckit:risk` | Concentration / single-supplier-dependency risk |
+| **Output** | `/arckit:adr` | Competitive landscape and route-to-market decisions recorded as ADRs |
+
+---
+
+## Follow-on Actions
+
+- Feed the competitive set into build-vs-buy analysis (`/arckit:research`)
+- Use rival award history as Company Experience evidence in a vendor scorecard (`/arckit:score`)
+- Register supplier-concentration or single-supplier-dependency risks (`/arckit:risk`)
+- Record route-to-market decisions as ADRs (`/arckit:adr`)
+- Escalate `HIGH` concentration findings to commercial lead before procurement scoping

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/conformance.md

@@ -0,0 +1,153 @@
+# Architecture Conformance Guide
+
+> **Guide Origin**: Official | **ArcKit Version**: [VERSION]
+
+`/arckit:conformance` checks whether the decided architecture (ADRs, principles) matches the designed architecture (HLD, DLD). It bridges `/arckit:health` (quick metadata scan) and `/arckit:analyze` (deep governance analysis) by focusing on decided-vs-designed conformance, architecture drift, and technical debt.
+
+---
+
+## When to Run
+
+| Cadence | Trigger | Notes |
+|---------|---------|-------|
+| Gate reviews | Alpha→Beta, Beta→Live | Attach conformance report to assurance packs |
+| After ADR changes | New ADR accepted or superseded | Confirm design still matches decisions |
+| After design revisions | HLD or DLD updated | Detect unintentional drift |
+| Quarterly | Live systems | Track technical debt trends and exception expiry |
+
+---
+
+## Inputs
+
+| Artefact | Contribution |
+|----------|--------------|
+| Architecture principles (MANDATORY) | Governance authority — design must conform |
+| ADRs (MANDATORY) | Decision authority — design must implement |
+| HLD / DLD | Design evidence for conformance checks |
+| HLD / DLD reviews | Review conditions to track resolution |
+| Risk register, compliance docs | Exception context and remediation tracking |
+| `.arckit/conformance-rules.md` | Project-specific constraint rules |
+
+---
+
+## Command
+
+```bash
+/arckit:conformance <project description>
+```
+
+Output saved as `projects/<id>/ARC-<id>-CONF-v1.0.md`.
+
+---
+
+## 12 Conformance Checks
+
+| ID | Check | Severity | What It Validates |
+|----|-------|----------|-------------------|
+| ADR-IMPL | ADR Decision Implementation | HIGH | Each accepted ADR's decision reflected in HLD/DLD |
+| ADR-CONFL | Cross-ADR Consistency | HIGH | ADRs don't contradict each other |
+| ADR-SUPER | Superseded ADR Enforcement | MEDIUM | Design doesn't reference superseded decisions |
+| PRIN-DESIGN | Principles-to-Design Alignment | HIGH | Binary pass/fail constraint check against principles |
+| COND-RESOLVE | Review Condition Resolution | HIGH | "Approved with conditions" have resolution evidence |
+| EXCPT-EXPIRY | Exception Register Expiry | HIGH | Approved exceptions haven't expired |
+| EXCPT-REMEDI | Exception Remediation Progress | MEDIUM | Active exceptions show remediation progress |
+| DRIFT-TECH | Technology Stack Drift | MEDIUM | Technologies in ADRs match HLD/DLD/DevOps artifacts |
+| DRIFT-PATTERN | Architecture Pattern Drift | MEDIUM | Chosen patterns consistently applied across artifacts |
+| RULE-CUSTOM | Custom Constraint Rules | Variable | User-defined rules from `.arckit/conformance-rules.md` |
+| ATD-KNOWN | Known Technical Debt | LOW | Catalogue acknowledged debt from ADR negatives, risks, workarounds |
+| ATD-UNTRACK | Untracked Technical Debt | MEDIUM | Detect potential debt not explicitly acknowledged |
+
+---
+
+## Custom Conformance Rules
+
+Create `.arckit/conformance-rules.md` to define project-specific constraints:
+
+```markdown
+# Conformance Rules
+
+1. All API services MUST use OAuth 2.0 for authentication
+2. Database connections MUST NOT use plaintext credentials
+3. All microservices SHOULD expose health check endpoints
+4. Logging MUST follow the structured JSON format defined in ADR-003
+```
+
+Keywords determine severity:
+
+- **MUST / MUST NOT** → HIGH severity
+- **SHOULD / SHOULD NOT** → MEDIUM severity
+
+---
+
+## Output Structure
+
+| Section | What It Contains |
+|---------|-----------------|
+| Executive Summary | Conformance score, recommendation (Conformant / With Exceptions / Non-Conformant) |
+| Conformance Scorecard | All 12 checks with PASS/FAIL/NOT ASSESSED |
+| ADR Decision Conformance | Implementation status, cross-ADR conflicts, superseded residue |
+| Design-Principles Alignment | Binary constraint checking per principle |
+| Review Condition & Exception Tracker | Unresolved conditions, exception status |
+| Architecture Drift Analysis | Technology drift, pattern drift |
+| Custom Constraint Rules | Results of user-defined rules |
+| Architecture Technical Debt Register | Known ATD, untracked ATD, metrics, trends |
+| Findings & Remediation Plan | Prioritised by severity with owners and deadlines |
+| Recommendations | Immediate, short-term, medium-term, governance |
+
+---
+
+## Conformance Scoring
+
+| Rating | Criteria | Gate Decision |
+|--------|----------|---------------|
+| **CONFORMANT** | All checks PASS (or NOT ASSESSED) | ✅ Proceed |
+| **CONFORMANT WITH EXCEPTIONS** | Some FAIL but LOW/MEDIUM with plans, >= 80% | ⚠️ Conditional proceed |
+| **NON-CONFORMANT** | Any HIGH FAIL or < 80% | ❌ Block until resolved |
+
+---
+
+## Architecture Technical Debt Categories
+
+| Category | Description |
+|----------|-------------|
+| DEFERRED-FIX | Known deficiency deferred to later phase |
+| ACCEPTED-RISK | Risk consciously accepted as trade-off |
+| WORKAROUND | Temporary solution deviating from intended pattern |
+| DEPRECATED-PATTERN | Superseded pattern not yet migrated |
+| SCOPE-REDUCTION | Quality/feature removed for timeline/budget |
+| EXCEPTION | Approved principle exception with expiry |
+
+---
+
+## Relationship to Other Commands
+
+```text
+/arckit:health          Quick metadata scan (stale files, missing links)
+         ↓
+/arckit:conformance     Systematic decided-vs-designed check (this command)
+         ↓
+/arckit:analyze         Deep governance across all dimensions
+```
+
+- **/arckit:principles-compliance** provides RAG scoring with remediation plans; **conformance** does binary pass/fail constraint checking
+- **/arckit:traceability** maps requirements to design; **conformance** maps decisions to design
+- **/arckit:health** checks file freshness and metadata; **conformance** checks architectural integrity
+
+---
+
+## Checklist
+
+- All accepted ADRs have corresponding design evidence.
+- No superseded ADR patterns remain in current design.
+- Review conditions from HLD/DLD reviews are resolved.
+- Exceptions have valid expiry dates and remediation plans.
+- Technology stack matches ADR decisions with no undocumented additions.
+- Architecture patterns are consistently applied.
+- Known technical debt is catalogued with owners and timelines.
+- Custom rules (if defined) are satisfied.
+
+---
+
+## Tip
+
+Run conformance checks after each design review cycle. The trend comparison (vs previous assessment) makes conformance drift visible over time — useful for governance boards and audit evidence.

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/create.md

@@ -0,0 +1,61 @@
+# FDE Site Generator Guide
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit-fde:create` generates a brandable Forward Deploy Engineering consulting site into
+`docs/`. It interviews the user for market preset, brand, pricing, contact details, CTA, and site
+metadata, then writes `fde-site.config.yaml` so the site can be regenerated later.
+
+---
+
+## When to Use
+
+- You need a white-label FDE consulting website for GitHub Pages or another static host.
+- You want a repeatable site generator rather than hand-editing `docs/index.html`.
+- You need market-specific copy, pricing tiers, worked examples, and discovery metadata.
+- You want to hand-edit a saved configuration and regenerate the site consistently.
+
+---
+
+## Command
+
+```bash
+/arckit-fde:create
+```
+
+Primary outputs:
+
+| Output | Purpose |
+|--------|---------|
+| `fde-site.config.yaml` | Saved site configuration for future regeneration |
+| `docs/index.html` | Generated static website |
+| `docs/assets/*` | Copied or generated visual assets |
+| `docs/llms.txt` | Discovery metadata when enabled by the template |
+
+---
+
+## Workflow
+
+1. Run `/arckit-fde:create` from the repository that should receive the site.
+2. Pick a preset: UK Public Sector, Generic, or Custom.
+3. Confirm brand, colours, pricing, contact, booking URL, and CTA text.
+4. Review before overwriting an existing `docs/index.html`.
+5. Commit the generated `docs/` site and `fde-site.config.yaml`.
+
+---
+
+## Guardrails
+
+- The command should not overwrite an existing `docs/index.html` without confirmation.
+- Keep `fde-site.config.yaml` under version control if the site is intended to be repeatable.
+- Use a valid hex brand colour and a canonical `site_url` with a trailing slash.
+- Treat generated copy as a starting point; review claims, pricing, and contact routes before
+  publishing.
+
+---
+
+## Related Commands
+
+- `/arckit:pages` - Generate an ArcKit project documentation site.
+- `/arckit:story` - Produce a stakeholder narrative for project evidence.
+- `/arckit:presentation` - Generate board-ready presentation material.