node scripts/ims.mjs apply PLAN.json \
  --expected-version VERSION \
  --plan-sha256 HASH \
  --allow-mutation

---
name: ims-process-review
host: [ArchLinux-dev, NB-00718]
description: "Use for Confluence IMS/ISO process reviews and Document Owner maintenance. Triggers: IMS, ISO-Prozess, ims-dokument, Prozessprüfung, Prozessreport, Prüfung, Freigabe."
---

# IMS Process Review

Maintain and review IMS processes according to the current official workflow.
Oliver decides operational truth; never demand evidence.

## Boundaries

- Use `scripts/ims.mjs` for deterministic policy checks, worklists,
  snapshots, approved writes, and validation.
- Never use browser automation.
- Process one page at a time after collecting the complete worklist.
- Referenced documents remain read-only context.
  Changing one requires its own plan and confirmation;
  IMS documents independently follow this workflow.
- A yearly review is the maximum interval,
  not a prohibition on an earlier review.
- A Document Owner cannot formally review their own document.
- `Geprüft von` names the person who actually performs the current review.
  Never rewrite historical review attribution to make it appear valid.

## Choose the mode

Choose explicitly before analysis:

- **Reviewer:** Oliver is `Geprüft von` and the page is in `Prüfung`.
- **Owner:** Oliver is `Document Owner` and must prepare, correct,
  or initiate a review cycle.
- **Direct page:** classify Oliver's role from the current IMS header,
  then follow the matching mode.

## Start every run

From this skill directory:

1. Read [the policy baseline](references/policy-baseline.md).
2. Run `node scripts/ims.mjs policy`.
3. If either policy version changed, show a compact version diff and stop.
   Ask Oliver for interpretation and propose the exact baseline or skill
   update.
   Even a change without an apparent policy delta requires confirmation.
4. Run `node scripts/ims.mjs worklist --mode reviewer` or
   `node scripts/ims.mjs worklist --mode owner`.
5. Use the complete report result across `isp`, `GA`, `RD`, `CS`, and `SM`.
   Treat `R&D` as `RD`; sort `RD` first and omit no area.
6. List malformed or incomplete IMS headers separately,
   only within Oliver's candidate set.

Owner candidates include drafts, missing or self-assigned reviewers,
malformed headers, and documents at the annual limit.
An earlier direct review remains valid even when it is absent from the
automatic owner worklist.

## Capture one process

Run `node scripts/ims.mjs snapshot PAGE_ID` before analysis.
Use that single-version snapshot to check:

- required IMS header structure and values;
- internal contradictions;
- contradictions with other current `ims-dokument` pages,
  checking directly referenced pages first;
- accessible links and references;
- spelling, grammar, formal ISP wording, and formatting;
- existing open inline comments as non-blocking context.

Mark inaccessible links `unverifiziert`, never `defekt`.
Do not reject solely because access is unavailable.
Treat non-IMS targets only as links to verify.
Do not inspect Jira issues, databases, files, or external sources for
semantic evidence unless Oliver explicitly asks.
Do not infer operational truth beyond Oliver's statements and current IMS
documents.

## Owner mode

Present each semantic or operational concern as one concrete question.
Discuss one question at a time and accumulate Oliver's decisions.
Do not turn an unconfirmed hypothesis into a finding.

Classify changes:

- Meaning-neutral wording, spelling, grammar, and formatting may remain in
  the current status.
- Semantic, logical, or process changes require `Entwurf`.
- A malformed IMS header requires an exact repair in `Entwurf`;
  reload and restart after validation.
- Review and release dates describe an attested version.
  Clear obsolete dates when beginning a renewed cycle;
  do not preserve them as current evidence after semantic change.

When the document is ready:

- set `Geprüft von` to the actual future reviewer,
  who must differ from the Document Owner;
- set `Status` to `Prüfung`;
- after `Entwurf`, use version comment `zur Prüfung freigegeben`;
- for an unchanged annual renewal moved directly to `Prüfung`,
  clear `Geprüft am` and `Freigegeben am`,
  then use `Prozess geprüft und auf Prüfung gesetzt`.

## Reviewer mode

Classify findings:

- Meaning-neutral wording, spelling, grammar, and formatting may be corrected
  while the page remains in `Prüfung`.
- Never create inline comments for meaning-neutral findings;
  include them in the direct correction diff.
- Any semantic or logical change requires `Entwurf`.
- The reviewer creates inline comments for approved semantic findings.
- Existing open comments are context and do not block a new review.

If accepted:

1. Save meaning-neutral corrections as a separate version with comment
   `Rechtschreibkorrektur`, then validate it.
2. Set `Geprüft am` to today's local date.
3. Set `Status` to `Freigabe` with version comment `geprüft`.
4. Keep all owner assignments unchanged.

If rejected:

1. Create and validate every approved inline comment.
2. Only after all comments and page markers are visible,
   set `Status` to `Entwurf` with version comment
   `zurück in Entwurf, da Korrektur notwendig`.
3. If any comment fails, leave status unchanged and report exactly which
   comments exist or are missing.

The Document Owner processes and closes comments,
then returns the page to `Prüfung`.

## Freeze the plan

Before any write, show:

1. title, direct URL, area, role, and captured version;
2. existing open inline comments;
3. each finding, its classification, and Oliver's decisions;
4. one readable rendered-text diff covering every planned body change;
5. each inline comment with exact quoted target and text;
6. every metadata transition and version comment;
7. ordered writes and resulting status.

Create one plan JSON for exactly one page.
Use the schema from `node scripts/ims.mjs --help`.

- `ok` accepts and freezes the displayed plan;
  it never authorizes a write.
- After `ok`, run `node scripts/ims.mjs check-plan PLAN.json`
  and report its hash.
- Only a later explicit `go` authorizes `apply` for that exact page,
  version, plan file, and hash.
- Any plan change invalidates the hash and requires a new display and `ok`.

## Apply and validate

After `go`, run:

```text
node scripts/ims.mjs apply PLAN.json \
  --expected-version VERSION \
  --plan-sha256 HASH \
  --allow-mutation
```

The helper must stop on version drift, ambiguous replacements,
missing comment targets, marker loss, unexpected version comments,
or semantic storage differences.
Never roll back automatically.
A failed post-write validation requires an observed-state report
and a separately confirmed correction plan.

## Receipt

After every mutation, include the direct page URL in the next response.
For each completed page, report resulting version, status, `Geprüft am`,
version comment, inline-comment result, plan hash, and validation result.