docs: enigma updates (other repo files) and improvements

The following files are pulled from other repositories:

- (example) `file name` - source repository path -> documentation path

- `README.md` - _/backend/definitions/_ -> _/docs/tech/architecture/definitions/_

- `CHANGELOG.md` - _/backend/definitions/_ -> _/docs/tech/architecture/definitions/_

- `openapi.yml` - _/backend/_ -> _/docs/tech/api/_

- `showcase-definition.zip` - _/definition-registry/_ -> _/files-from-repos/showcase-definition.zip_

- `introductory-definition.zip` - _/definition-registry/_ -> _/files-from-repos/intro-definition.zip_

- `users.md` - _/docker-deployment/_ -> _/docs/tech/installation/users.md_

- `troubleshooting.md` - _/docker-deployment/_ -> _/docs/tech/installation/troubleshooting.md_

- `README.md` - _/docker-deployment/_ -> _/docs/tech/installation/setup.md_

- `installation.md` - _/docker-deployment/_ -> _/docs/tech/installation/overview.md_

- `README.md` - _/docker-deployment/https-owncert/_ -> _/docs/tech/installation/https/owncert.md_

- `README.md` - _/docker-deployment/https/_ -> _/docs/tech/installation/https/base-setup.md_

- (example) `file name` – source repository path -> documentation path

- `README.md` – _/backend/definitions/_ -> _/docs/tech/architecture/definitions/_

- `CHANGELOG.md` – _/backend/definitions/_ -> _/docs/tech/architecture/definitions/_

- `openapi.yml` – _/backend/_ -> _/docs/tech/api/_

- `showcase-definition.zip` – _/definition-registry/_ -> _/files-from-repos/showcase-definition.zip_

- `introductory-definition.zip` – _/definition-registry/_ -> _/files-from-repos/intro-definition.zip_

- `users.md` – _/docker-deployment/_ -> _/docs/tech/installation/users.md_

- `troubleshooting.md` – _/docker-deployment/_ -> _/docs/tech/installation/troubleshooting.md_

- `README.md` – _/docker-deployment/_ -> _/docs/tech/installation/setup.md_

- `installation.md` – _/docker-deployment/_ -> _/docs/tech/installation/overview.md_

- `README.md` – _/docker-deployment/https-owncert/_ -> _/docs/tech/installation/https/owncert.md_

- `README.md` – _/docker-deployment/https/_ -> _/docs/tech/installation/https/base-setup.md_

### 3. update-links.sh

- Build Documentation: Use MkDocs to build the site.

- Deploy Pages (manual stage): Deploy the built documentation to GitLab Pages.

The deployment of the documentation is available via running the manual stage - Deploy Pages - to

The deployment of the documentation is available via running the manual stage – Deploy Pages – to

GitLab Pages upon successful completion of all previous stages. Most importantly the _Build

Documentation_ must be successful.

## How to start?

- The Editor is easily accessible through the INJECT Gateway - see the picture below.

- The Editor is easily accessible through the INJECT Gateway – see the picture below.

- Once you start using it, it will guide you through a structured process.

![Editor interface in INJECT Gateway](../../images/editor.png)

- Most of the typos and errors in the YAML format are caught by the validator in the platform.

- Markdown for Complex Texts: If there are any longer or more complex texts or responses (especially

    those with special characters), it is recommended to use markdown files in the content folder.

- If you use overlays, do not set them to start at minute 0 of the exercise - set them to minute 1

- If you use overlays, do not set them to start at minute 0 of the exercise – set them to minute 1

    instead. Otherwise, the overlay would not appear for trainees.

## Crucial Concepts

??? "Editor"

    The INJECT Exercise Platform now includes a new tool - the Editor - that makes exercise creation

    The INJECT Exercise Platform now includes a new tool – the Editor – that makes exercise creation

    more accessible and guided. While it's still in development, it offers a user-friendly alternative

    to manual YAML editing.

    - Instructors are key to the implementation of the exercise.

    - In the basic model we need one instructor per team.

    - Specialists? Not needed - their knowledge is embodied in the response templates.

    - Specialists? Not needed – their knowledge is embodied in the response templates.

    - If the instructors are not experienced you should have a dry run with them.

    ### Equipment and Materials

??? "Onboarding"

    Since the IXP may be new to many trainees, it makes sense to **let them to complete the introductory

    tutorial first**. Although the platform’s user interface is intuitive, having a structured\

    tutorial first**. Although the platform’s user interface is intuitive, having a structured

    overview is more beneficial than letting trainees figure it out during the actual exercise. **We

    have created a short introduction that will take no more than 15 minutes to help enhance their

    experience.**

## Log analysis

- If you have an external tool, you can utilize logs - see the

- If you have an external tool, you can utilize logs – see the

    [log specification](../../tech/log-format.md) for details.

## Trainee Performance Evaluation

Ordinary TTXs are usually unable to react in any way to the actions of trainees. IXP can do this on

multiple levels. Some injects types have this integrated by default:

- The instructor chooses one of the possible answers to the email - the chosen answer can be

- The instructor chooses one of the possible answers to the email – the chosen answer can be

    followed up with the following automatic action of the platform..

- Using reactions to free form injects - similarly, diffrent reactions can be linked to the

- Using reactions to free form injects – similarly, diffrent reactions can be linked to the

    following automatic action of the platform..

- Using decision points - each answer chosen can be associated with another automatic action of the

- Using decision points – each answer chosen can be associated with another automatic action of the

    platform.

- Hints - Hints are actually conditioned responses to trainees' behavior.

- Hints – Hints are actually conditioned responses to trainees' behavior.

However, the possibility of conditioning does not end there. Almost every action of the trainee that

is manifested in the platform, can be linked by the another automatic action. This is done by

it cannot be bypassed. A concrete example might be a situation where a designer thinks like this:

The final step in the exercise is the use of the tool "Convene Crisis Meeting". So we set the

condition that after activating it, a questionnaire with a final reflection is automatically sent to

the trainees. At first glance, everything looks logical, however, we have to ask ourselves - can the

trainees use the tool earlier? For example, because of a bad evaluation of the situation - if so, it

the trainees. At first glance, everything looks logical, however, we have to ask ourselves – can the

trainees use the tool earlier? For example, because of a bad evaluation of the situation – if so, it

cannot be expected that this will always happen at the end of the exercise and therefore the

condition set in this way is inappropriate.

- The platform allows us to create very specific types of scenarios that can combine diffrent types

    of injects, eg. email communication with interactive injects.

- Testing is essential when designing these types of exercises - because it is harder to know

- Testing is essential when designing these types of exercises – because it is harder to know

    whether the intended links between activities will be understood by trainees.

??? "Bonus: How to make exercise more fun?"