Use semantic coloring for code names in texts

docs/_preview/go.mod

@@ -3,7 +3,7 @@ module github.com/SpineEventEngine/documentation/docs/_preview
 go 1.22.0
 
 require (
-	github.com/SpineEventEngine/site-commons v0.0.0-20260213171221-c1157022c545 // indirect
+	github.com/SpineEventEngine/site-commons v0.0.0-20260217160941-2a1a87ca8cfb // indirect
 	github.com/SpineEventEngine/validation/docs v0.0.0-20260205202311-181ba8844107 // indirect
 	github.com/gohugoio/hugo-mod-bootstrap-scss/v5 v5.20300.20400 // indirect
 	github.com/gohugoio/hugo-mod-jslibs-dist/popperjs/v2 v2.21100.20000 // indirect

docs/_preview/go.sum

@@ -1,5 +1,5 @@
-github.com/SpineEventEngine/site-commons v0.0.0-20260213171221-c1157022c545 h1:NI8WYIfw5yv/FXNhxG2zgiU3J0YChheRQugosxkopoc=
-github.com/SpineEventEngine/site-commons v0.0.0-20260213171221-c1157022c545/go.mod h1:tkAl4StIREKmz9r5PiJtuDhvwMMkFXKWcaTyxhIikho=
+github.com/SpineEventEngine/site-commons v0.0.0-20260217160941-2a1a87ca8cfb h1:4OsCLSX35TznTy8qs/l8HkFUYKNPfMF/tgO1iYe9LfI=
+github.com/SpineEventEngine/site-commons v0.0.0-20260217160941-2a1a87ca8cfb/go.mod h1:tkAl4StIREKmz9r5PiJtuDhvwMMkFXKWcaTyxhIikho=
 github.com/SpineEventEngine/validation/docs v0.0.0-20260205202311-181ba8844107 h1:2DHRIwwLudP6l3Kh7Nd4KR4uXcsDtIAXE9adW68ivME=
 github.com/SpineEventEngine/validation/docs v0.0.0-20260205202311-181ba8844107/go.mod h1:STHyjXejVvPmfrxujfDvhofmjg55mMk+fwI3TVL0b4Y=
 github.com/gohugoio/hugo-mod-bootstrap-scss/v5 v5.20300.20400 h1:L6+F22i76xmeWWwrtijAhUbf3BiRLmpO5j34bgl1ggU=

docs/content/docs/examples/_index.md

@@ -19,7 +19,7 @@ Please see the selected list of the examples with the descriptions below.
 - [Kanban]({{% get-site-data "repositories.examples" %}}/kanban/) — shows orchestrating 
   Aggregates using Process Managers.
 - [Airport]({{% get-site-data "repositories.examples" %}}/airport/) — integrating 
-  a third-party systems using a Bounded Context. This example accompanies 
+  a third-party system using a Bounded Context. This example accompanies 
   the [“Integration with a Third Party”](docs/guides/integration/) guide.
 - [To-Do List]({{% get-site-data "repositories.examples" %}}/todo-list/) — a simple 
   task management system with multiple client applications. 
@@ -31,4 +31,4 @@ Please see the selected list of the examples with the descriptions below.
 - [Simple HTML/JS To-Do List client]({{% get-site-data "repositories.examples" %}}/todo-list/tree/master/client/html-js/)
   — a client app with very basic features.
 - [To-Do List client on Angular]({{% get-site-data "repositories.examples" %}}/todo-list/tree/master/client/angular/)
-  — a more featured client built with Angular 10.
+  — a more featured client built with Angular 10.

docs/content/docs/guides/integration.md

@@ -328,7 +328,7 @@ private void emitIfStatusKnown(TsaPassenger tsaPassenger) {
 }
 ```
 The [Process Manager]({{% get-site-data "repositories.examples" %}}/airport/blob/master/takeoffs-and-landings/src/main/java/io/spine/example/airport/tl/passengers/BoardingProcman.java)
-accumulates the Events and, once the whole *Flight* is boarded, emits a `BoardingComplete` event,
+accumulates the Events and, once the whole *Flight* is boarded, emits a {{< code "event" "BoardingComplete" >}} event,
 which is later consumed by the&nbsp;[*Flight* Aggregate]({{% get-site-data "repositories.examples" %}}/airport/blob/master/takeoffs-and-landings/src/main/java/io/spine/example/airport/tl/FlightAggregate.java).
 
 <embed-code file="examples/airport/takeoffs-and-landings/src/main/java/io/spine/example/airport/tl/passengers/BoardingProcman.java" 

docs/content/docs/guides/start-new-project.md

@@ -148,7 +148,7 @@ and polish the code of this important development step.
 ### Events
 
 When the IDs are defined it’s time to define [event][event-concept] messages. The events are named 
-as facts formulated as past participles, e.g. `RepositoryRegistered` or `TaskCreated`. 
+as facts formulated as past participles, e.g. {{< code "event" "RepositoryRegistered" >}} or {{< code "event" "TaskCreated" >}}. 
 They are defined in files with the [`_events.proto`][events-proto] suffix (e.g. `order_events.proto`, 
 `customer_events.proto`). If your context is small it can be just `events.proto`.
 
@@ -158,8 +158,8 @@ Create a Pull Request with the event definitions when they are ready.
 
 Similar to events, [command][command-concept] messages are defined in files having the names ending 
 with the [`_commands.proto`][commands-proto] suffix (or just `commands.proto` for a small context). 
-Commands are defined as imperative in a form of “do something”, e.g. `RegisterRepository` 
-or `CreateTask`.
+Commands are defined as imperative in a form of “do something”, e.g. 
+{{< code "command" "RegisterRepository" >}} or {{< code "command" "CreateTask" >}}.
 
 Finalize defining commands with a Pull Request.
 
@@ -189,8 +189,8 @@ The [entity state][entity-state-naming] is a holder of the entity data. It does
 a whole [entity][entity-concept] but depicts the shape of its data.
 
 The definitions of entity states are [gathered][entity-state-proto] in a file named after 
-a business model thing. E.g. for a `Task` aggregate, the definitions would be defined in 
-a `task.proto` file.
+a business model thing. E.g. for a {{< code "aggregate" "Task" >}} aggregate, the definitions 
+would be defined in a `task.proto` file.
 
 As with the other steps, create a Pull Request to review the entity states with the&nbsp;team.
 
@@ -208,7 +208,7 @@ the business logic the same way it works in the application.
 All the code must conform to your standards of the code and documentation quality 
 and be tested thoroughly.
 
-When a backend for the scenario is done a new PR is created and reviewed.
+When a backend for the scenario is done a new PR is created and&nbsp;reviewed.
 
 ### Fulfilling the vertical
 
@@ -221,7 +221,7 @@ with the previous one.
 As noted, the scope of this iteration is to prepare the front-facing part for the scenario: 
 either a UI if one is needed, or the public API, or a dedicated idiomatic client.
 
-As soon as the implementation is ready, another PR and review come along.
+As soon as the implementation is ready, another PR and review come&nbsp;along.
 
 ## Start over again
 

docs/content/docs/guides/validation.md

@@ -23,7 +23,7 @@ that define correctness of data are also defined at this level using custom Prot
 
 {{% note-block class="note" %}}
 In order to use validation features, you don't need to understand how custom
-options work. Those who are interested in the details of this <em>advanced feature</em> of Protobuf,
+options work. Those who are interested in the details of this _advanced feature_ of Protobuf,
 please see the [Protobuf Guide](https://developers.google.com/protocol-buffers/docs/proto3#custom_options)
 for details.
 {{% /note-block %}}
@@ -318,8 +318,8 @@ therefore it is implicitly required. By default, the framework will use it in co
 as an identifier of the entity handling this command.
 
 This convention does not apply to [Events](docs/introduction/naming-conventions#eventsproto).
-Unlike Commands, event routing is typically specific to the use case. For example, `UserView` projection
-may require a user ID to handle events, whereas the `ProfilePictureGallery` projection might use
+Unlike Commands, event routing is typically specific to the use case. For example, {{< code "projection" "UserView" >}} projection
+may require a user ID to handle events, whereas the {{< code "projection" "ProfilePictureGallery" >}} projection might use
 a different routing approach, such as grouping by a user group or an email domain associated with a user.
 
 Therefore, all Event fields are not required by default.

docs/content/docs/introduction/_index.md

@@ -150,11 +150,11 @@ final class TaskItemProjection
 #### Repositories
 The framework provides default implementations for repositories.
 A custom `Repository` class may be needed for:
-  * <strong>Dispatching messages to entities in a non-standard way</strong>.
+  * **Dispatching messages to entities in a non-standard way**.
     By default, a command is dispatched using the first field of the command message
     as an ID of the target entity.
     An event is dispatched by the ID of the entity which emitted the event.
-  * <strong>Domain-specific operations</strong> on entities of this kind.
+  * **Domain-specific operations** on entities of this kind.
 
 Repositories are added to the Bounded Context they belong when it is created:
 
@@ -170,8 +170,8 @@ This wires repositories into the message delivery mechanism of the corresponding
 
 #### Testing
 Implementation of the Bounded Context is tested using the messaging paradigm.
-The following code snippet asserts that handling a command `CreateTask` produces one 
-`TaskCreated` event with expected arguments.
+The following code snippet asserts that handling a command {{< code "command" "CreateTask" >}} 
+produces one {{< code "event" "TaskCreated" >}} event with expected arguments.
 
 ```java
 // Given

docs/content/docs/introduction/concepts.md

@@ -40,9 +40,9 @@ regular events. If an event is a fact of something that happened to a domain mod
 a fact that states the reason why a command was not handled.  
 
 Consider the following examples of rejections: 
-* `CreditCardValidationDeclined`, 
-* `OrderCannotBeEmpty`, 
-* `InsufficientFunds`.
+* {{< code "rejection" "CreditCardValidationDeclined" >}},
+* {{< code "rejection" "OrderCannotBeEmpty" >}},
+* {{< code "rejection" "InsufficientFunds" >}}.
 
 In Spine, rejections are defined as Protobuf messages in the file which names ends with
 `rejections.proto`. 
@@ -85,8 +85,8 @@ final class TaskAggregate
 
 Event Subscriber is an object which subscribes to receive events.
 
-The example below shows how a [Projection](#projection) class subscribed to the `TaskCompleted`
-event.
+The example below shows how a [Projection](#projection) class subscribed 
+to the {{< code "event" "TaskCompleted" >}} event.
 
 ```java
 final class TaskProjection

docs/content/docs/introduction/naming-conventions.md

@@ -91,10 +91,10 @@ an event, and it is likely there are conditions under which a command cannot be
 ### Entity states
 
 We recommend gathering definition of related entity states in a file named after a business model
-thing. Suppose we have a `Task` aggregate, `TaskItem` and `TaskDetails` projections, and
-a Process Manager which is responsible for movement of a task from one project to another, there
-would be `task.proto` file, with all Task-related data types definitions. A project-related data
-types would be defined in a `project.proto` file. 
+thing. Suppose we have a {{< code "aggregate" "Task" >}} aggregate, {{< code "projection" "TaskItem" >}} 
+and {{< code "projection" "TaskDetails" >}} projections, and a Process Manager which is responsible for 
+movement of a task from one project to another, there would be `task.proto` file, with all Task-related 
+data types definitions. The project-related data types would be defined in a `project.proto` file. 
 
 As it was already mentioned, `TaskId` and `ProjectId` are defined in the `identifiers.proto` file,
 and `task.proto` and `project.proto` import this file.
@@ -222,26 +222,26 @@ message CreateTask {
 
 A command is defined as an imperative:
 
- * `CreateProject`
- * `AssignTask`
- * `RemoveComment`
+ * {{< code "command" "CreateProject" >}}
+ * {{< code "command" "AssignTask" >}}
+ * {{< code "command" "RemoveComment" >}}
 
 ### Events
 
 Events are named as facts formulated as past participles, for example:
 
-  * `ProjectCreated`
-  * `TaskAssigned`
-  * `CommentRemoved`   
+  * {{< code "event" "ProjectCreated" >}}
+  * {{< code "event" "TaskAssigned" >}}
+  * {{< code "event" "CommentRemoved" >}}
 
 ### Rejections
 
 A rejection is named after a reason of why a command cannot be handled. In fact, rejection notifies
 on a state of the domain model, for example:
 
-  * `TaskAlreadyExists`
-  * `InsufficientFunds` 
-  * `ProjectAlreadyCompleted`
+  * {{< code "rejection" "TaskAlreadyExists" >}}
+  * {{< code "rejection" "InsufficientFunds" >}}
+  * {{< code "rejection" "ProjectAlreadyCompleted" >}}
 
 ### Entity states