Restructure of docs, ordered stages

.github/actions/spelling/allow.txt

@@ -284,4 +284,4 @@ nonprod
 plpgsql
 pg_stat_statements
 pg_buffercache
-
+JIRA

source/cjs-common-platform/index.html.md.erb

@@ -1,6 +1,6 @@
 ---
 title: CJS Common Platform
-weight: 4
+weight: 11
 ---
 
 # <%= current_page.data.title %>

source/cloud-native-platform/standards/apis.html.md.erb → source/concepts-standards/apis/index.html.md.erb

@@ -3,7 +3,6 @@ title: API design
 last_reviewed_on: 2023-08-16
 review_in: 12 months
 weight: 2
-hide_in_navigation: true
 ---
 
 # <%= current_page.data.title %>

source/cloud-native-platform/standards/db-schema-change.html.md.erb → source/concepts-standards/db-schema/index.html.md.erb

@@ -3,7 +3,6 @@ title: Database schema changes
 last_reviewed_on: 2023-02-22
 review_in: 6 months
 weight: 3
-hide_in_navigation: true
 ---
 
 # <%= current_page.data.title %>

source/concepts-standards/index.html.md.erb

@@ -0,0 +1,40 @@
+---
+title: Concepts and standards
+last_reviewed_on: 2023-02-24
+review_in: 6 months
+weight: 2
+---
+
+# <%= current_page.data.title %>
+Standards are a low level specification of how a particular technology should be used. Where possible, standards should be implemented through tooling and libraries rather than documentation.
+
+
+# Principles, practices and standards
+
+DTS define the principles, practices and standards that apply to all digital services in HMCTS. Principles are abstract
+ideas and values which DTS holds independent of the specific area of the business. For example, Crime and CFT may have
+different Practices or Standards in areas but they hold the same shared Principles.
+
+![DTS Overview](./images/overview.png)
+
+### Principles
+
+Principles are high level concepts that are used to guide the design of the system. They are not specific to any particular component or feature, and can be applied in a broad manner.
+
+### Practices
+
+Practices are concepts that are applicable within specific contexts such as a particular language, framework, or technology.
+
+### Standards
+
+Standards are a low level specification of how a particular technology should be used. Where possible, standards should be implemented through tooling and libraries rather than documentation.
+
+
+- Apps must adhere to [Twelve-Factor](https://12factor.net) principles
+- All pipelines must follow the [common build pipeline](../common-pipeline/)
+- Use standardised [environments](../environments/)
+- Testing
+- Deployment
+- Release
+  - [Feature flags](../new-component/feature-flags.html#feature-flags)
+- [Branching strategies](../new-component/feature-flags.html#trunk-based-development)

source/concepts-standards/practices/apis.html.md.erb

@@ -0,0 +1,24 @@
+---
+title: APIs
+weight: 3
+---
+
+# <%= current_page.data.title %>
+
+### API Design and implementation
+
+Use the [HMCTS RESTful API standards](https://hmcts.github.io/restful-api-standards/).
+
+### Versioning
+
+Use content type negotiation or endpoint naming to version the API.
+
+Do not make backward incompatible changes to existing endpoints.
+
+See the official guidance in the [TGL](https://tools.hmcts.net/confluence/pages/viewpage.action?pageId=1611204737&__ncforminfo=TeykTRO7uMi-mDnly8SmjuKluB1u3rrwwlwGkfYwyuBtTvzhtdiq1QymGuTr5WAl0bULwsGc4_Kv4lvc4ja_Tf4s4wSlGOiC)
+
+### Documentation
+
+Use [OpenAPI](https://swagger.io/specification/) for API documentation.
+
+Maintain a central repository of API documentation.

source/concepts-standards/practices/backends.html.md.erb

@@ -0,0 +1,39 @@
+---
+title: Backend applications
+weight: 2
+---
+
+# <%= current_page.data.title %>
+
+APIs should be written using Java, preferably with an industry standard framework such.
+
+### Java
+
+Use the current LTS version. Ensure that there is a process in place to upgrade it as new versions released.
+
+### Dependency management
+
+Ensure dependabot or renovate has been configured so that dependencies are kept up to date.
+
+### Build tools
+
+Use gradle or maven to build the application. Ant is not recommended.
+
+### Code style
+
+Use the [Google Java Style Guide](https://google.github.io/styleguide/javaguide.html) or a derivative.
+
+Set up tooling to enforce coding standards such as checkstyle or spotless.
+
+### Security
+
+Use [OWASP](https://owasp.org/) or [Snyk](https://snyk.io/) for dependency scanning.
+
+### Documentation
+
+Use [OpenAPI](https://swagger.io/specification/) for API documentation.
+
+Using JavaDoc is not necessary.
+
+Documentation should not explain what the code is doing, but can be used to clarify why it is doing it.
+

source/concepts-standards/practices/certificates.html.md.erb

@@ -0,0 +1,19 @@
+---
+title: Certificates
+weight: 4
+---
+
+# <%= current_page.data.title %>
+
+### Automate
+
+Ensure that SSL certificates are automated and renewed regularly.
+
+Use services such as [Microsoft managed certificates](https://docs.microsoft.com/en-us/azure/frontdoor/front-door-custom-domain-https#option-1-default-use-a-certificate-managed-by-front-door) or [LetsEncrypt](https://letsencrypt.org/) to automate the process of obtaining and renewing SSL certificates.
+
+### TLS
+
+Use TLS 1.3 with a 2048-bit RSA or 256-bit ECDSA key.
+
+Do not use TLS 1.0 or 1.1.
+

source/concepts-standards/practices/frontend.html.md.erb

@@ -0,0 +1,54 @@
+---
+title: Frontend applications
+weight: 1
+---
+
+# <%= current_page.data.title %>
+
+Citizen frontend applications should be built using a node.js based Server Side Rendering (SSR) framework such as Express.
+
+Professional frontend applications should be built using a node.js based Single Page Application (SPA) framework such as Angular.
+
+Both citizen and professional applications should be based on the [GOV.UK Design System](https://design-system.service.gov.uk/) and use
+[GOV.UK Frontend](https://frontend.design-system.service.gov.uk/) or a derivative such as [HMCTS Frontend](https://hmcts.github.io/hmcts-frontend/).
+
+### Node.js
+
+Use the current LTS version. Ensure that there is a process in place to upgrade it as new versions released.
+
+Deno is not currently recommended.
+
+### Dependency management
+
+Ensure dependabot or renovate has been configured so that dependencies are kept up to date.
+
+NPM or Yarn is acceptable.
+
+### TypeScript
+
+TypeScript is recommended for all new projects.
+
+### Browser support
+
+Applications should support the latest version of Chrome, Edge, Firefox and Safari.
+
+Where possible applications should aim to use a responsive layout in order to work on mobile devices.
+
+### Code style
+
+Use an opinionated code linter such as eslint and code formatter such as prettier to eliminate discussions about subjective coding preferences.
+
+### Accessibility
+
+Use Pa11y for accessibility testing to WCAG 2.1 AA.
+
+### Cross-browser and UI testing
+
+Use playwright or cypress to test applications in the browser.
+
+### Security
+
+Configure the Content Security Policy headers to prevent XSS attacks.
+
+Add CSRF protection to forms to ensure that they cannot be submitted by a third party.
+

source/concepts-standards/practices/index.html.md.erb

@@ -0,0 +1,13 @@
+---
+title: Practices
+weight: 2
+# hide_in_navigation: true
+---
+
+# <%= current_page.data.title %>
+
+Practices are concepts that are applicable within specific contexts such as a particular language, framework, or technology.
+
+<% current_page.children.each do |page| %>
+- [<%= page.data.title %>](<%= page.url %>)
+<% end %>

source/concepts-standards/principles/continuous-delivery.html.md.erb

@@ -0,0 +1,44 @@
+---
+title: Continuous delivery
+weight: 2
+---
+
+# <%= current_page.data.title %>
+
+All teams should use a Continuous Integration and Continuous Delivery pipeline.
+
+[Trunk Based Development](https://trunkbaseddevelopment.com/) is the recommended branching strategy for continuous delivery:
+
+- All changes integrate into the trunk
+- If branches from the trunk are used:
+  - They originate from the trunk
+  - They re-integrate to the trunk
+  - They are short-lived and removed after the merge
+
+Git-flow is [not recommended](https://nvie.com/posts/a-successful-git-branching-model/), even by the original author.
+
+## Principles of Continuous Delivery
+
+### Early feedback
+
+Ensure automated tests are run as often as possible (preferably when ever a chance is made) to the branch which is to be merged in.
+
+### Early integration
+
+Integrating early and often will help avoid complicated merge conflicts and ensure that the code is always in a releasable state.
+
+### Early business input
+
+To ensure smooth flow of work being deployed, it is important that The Business/Product Owner sign off tickets to be released to production as soon as possible. Before work begins, it needs to be agreed whether or not a Feature Flag is needed to allow for code to be deployed into production, prior to a business release being approved. This could be to allow for time for staff training or legislation to be announced.
+
+### Release as frequently as possible
+
+The more often a change is released, the lower the risk of a change being deployed for a long time and the easier it is to rollback. Releasing often gives developers confidence in, and understanding of the deployment process. Pipelines should be well maintained and reliable.
+
+### Release as small as possible
+
+The smaller the change, the lower the risk, the easier to rollback and the simpler to debug any issues which may arise from the deployment.
+
+### Backward compatible only
+
+Avoid making any breaking changes to ensure rollbacks are very simple (or fix forward).

source/concepts-standards/principles/devops.html.md.erb

@@ -0,0 +1,26 @@
+---
+title: DevOps
+weight: 3
+---
+
+# <%= current_page.data.title %>
+
+DevOps is not a job title. It's a culture. It is not just about infrastructure. It's about the people, processes, and tools that make it all work.
+
+### Infrastructure as code
+
+Infrastructure should be provisioned from code. This allows for the infrastructure to be versioned, tested, and deployed. It also allows for the infrastructure to be easily recreated in the event of a disaster.
+
+### You build it, you run it
+
+Delivery team's should be responsible for their own infrastructure. This means team's should be able to troubleshoot and fix issues with the infrastructure.
+
+Applications should be run, monitored and scaled by the team that built it.
+
+### Automate everything
+
+Everything should be automated. This includes provisioning, configuration, deployment, and monitoring.
+
+### Containers
+
+Use containers to package applications. This allows for applications to be easily deployed and scaled.

source/concepts-standards/principles/index.html.md.erb

@@ -0,0 +1,12 @@
+---
+title: Principles
+weight: 2
+---
+
+# <%= current_page.data.title %>
+
+Principles are high level concepts that are used to guide the design of the system. They are not specific to any particular component or feature, and can be applied in a broad manner.
+
+<% current_page.children.each do |page| %>
+- [<%= page.data.title %>](<%= page.url %>)
+<% end %>

source/concepts-standards/principles/programming.html.md.erb

@@ -0,0 +1,23 @@
+---
+title: Programming
+weight: 2
+---
+
+# <%= current_page.data.title %>
+
+## General principles
+
+- YAGNI - [You Aren't Gonna Need It](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it)
+- KISS - [Keep It Simple, Stupid](https://en.wikipedia.org/wiki/KISS_principle)
+- Security baked-in not bolted on - [Cloud Security Principles](https://www.ncsc.gov.uk/collection/cloud/the-cloud-security-principles)
+- Transparency - [work in the open](https://www.gov.uk/guidance/be-open-and-use-open-source)
+- Peer review - [nothing gets to production without peer review](https://en.wikipedia.org/wiki/Peer_review)
+- Egoless programming - [you are not your code](https://blog.codinghorror.com/the-ten-commandments-of-egoless-programming/)
+- Domain Driven Design - [design around the domain](https://en.wikipedia.org/wiki/Domain-driven_design)
+
+## Object oriented programming
+
+- SOLID - [Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion](https://en.wikipedia.org/wiki/SOLID)
+- Composition over inheritance - [prefer composition over inheritance](https://en.wikipedia.org/wiki/Composition_over_inheritance)
+- Law of Demeter - [talk to friends, not strangers](https://en.wikipedia.org/wiki/Law_of_Demeter)
+