DirXMLDev

DirXMLDev is a Designer-optional toolchain for OpenText / NetIQ Identity Manager. The driver set lives as files (IDM-as-code). You change those files with bin/idm, prove them with the engine's own compilers and the DirXML Policy Simulator, then deploy and operate the Identity Vault over LDAPS and DirXML extended operations. Designer stays an import/export target for teams that still use it.

A human operator and an agent run the same commands. The tree in git is the source of truth. The vault is a deploy target.

Policy flow

DirXMLDev Visual draws the Designer-style policy-flow fishbone in Cursor or VS Code, from bin/idm query … fishbone. Command Palette → DirXMLDev: Show Policy Flow (Fishbone), or right-click driver.xml or driverset.xml. It does not write the tree or talk to a vault.

Who it is for

• An IDM engineer who wants policies, filters, GCVs, forms, and workflows in git, with a diff and a snapshot before anything is written to a vault.
• An agent doing that loop under the same safety rules. The interface is bin/idm. How to point Claude Code, Cursor, or any other agent at it is docs/agents.md.
• A team that still opens Designer: export and export-project hand the tree back as a configuration file or an updated project.

What you can do

import  →  edit  →  validate  →  simulate  →  vault.diff / vault.deploy  →  operate

Step	Command	What you get
Bring a driver set in	import, import-project, import-ldif, import-live	One readable file per object under tree/
See what is there	query, show, refs, docs, query fishbone	Chains, GCVs, who references what, a generated write-up, the policy-flow fishbone
Change it	edit the policy file, or an operation (policy.add, gcv.set, form.field.add, flow.activity.add, package.install, …)	A transaction: load, apply, validate, write only if no new error
Check it offline	validate	The engine's compilers, in the driver's context, plus linkage, GCV, filter, form, and flow checks
Prove a policy change	simulate --cases … --against …	The regression corpus run on the new tree and diffed against the previous tree
See the vault delta	vault.diff	Per-object added / changed / removed. Nothing is written
Deploy	vault.deploy --dry-run, then --yes or --step	Plan, LDIF snapshot, LDAP writes, driver restart, re-read, an audit line
Operate	driverset.status, driver.start / stop / restart, cache, trace, migrate, resync, secrets, submit	The same environments and audit log as deploy
Read a trace	driver.trace tail --ldap, driver.trace view	The engine's trace over LDAP in the terminal, or opened in the DirXML Trace Viewer on the desktop, live with a driver selected or from a file
Prove a workflow	bin/apps	Identity Applications REST: request, tasks, approve, history
Hand it back	export, export-project	A Designer driver-set export, or an update of an existing project

The VS Code / Cursor extension in Policy flow draws that fishbone. It does not write the tree or talk to a vault.

The DirXML Trace Viewer is Point Blue's desktop viewer for driver trace: live over LDAP with syntax colouring, filters and find, or a trace file of any size. bin/idm viewer.install fetches its latest release, checksum verified, and driver.trace view --env stg --driver "AD Driver" (or --file trace.log) opens it, so a person reads the trace in the viewer while the agent works in the terminal (docs/install.md §5.2).

bin/idm with no arguments lists every command and flag. That text is the contract. Where an older design note disagrees with it, follow bin/idm.

Quick start

Recommended: let a coding agent set this up. Open docs/agent-assisted-setup.md, paste the kickoff prompt into Claude Code, Cursor, Codex or any agent that reads files and runs a shell, and watch. The agent installs JDK 21 and Maven, builds the simulator and bin/idm, finds the engine jars, writes your client directory with a redacted environments.properties, stores the vault password out of the file, and stops at each checkpoint for you to look. It ends on read-only checks against your vault, under an hour on a machine that has the jars. Nothing is written to the vault during setup. The commands below are what you and the agent run once that is done.

The commands assume bin/idm is built and you are in a client directory (not this repository). Setting that directory up by hand, including a redacted environments.properties, is docs/getting-started.md; building from source by hand is docs/install.md. Names such as stg and AD Driver are placeholders for your environment name and your driver's name.

bin/idm import-live tree/ --env stg
bin/idm validate tree/
bin/idm vault.diff tree/ --env stg
bin/idm query tree/ chain "AD Driver" sub
bin/idm query tree/ drivers

A policy change, then a staging deploy. Read the dry-run before --yes.

bin/idm policy.add tree/ --driver "AD Driver" --scope subscriber \
  --name "ACME-sub-ctp-NormalizeTitle" --link subscriber-command \
  --content-file normalize-title.policy.xml
bin/idm validate tree/
bin/idm simulate tree/ --cases cases/ --against /path/to/tree-before
bin/idm vault.diff tree/ --env stg
bin/idm vault.deploy tree/ --env stg --driver "AD Driver" --dry-run
bin/idm vault.deploy tree/ --env stg --driver "AD Driver" --yes

Production is the same commands plus the gate. A person types the environment name after --confirm. Values that differ per stage, such as the AD domain name, live in one file per environment beside the tree; the deploy applies the target's file and the tree keeps the base value (docs/getting-started.md §3.1):

cat overrides/prd.properties
# drivers/AD Driver.gcv.drv.domain.dns.name = corp.example.com
bin/idm vault.deploy tree/ --env prd --driver "AD Driver" --dry-run
bin/idm vault.deploy tree/ --env prd --driver "AD Driver" --yes --confirm prd

More workflows, including forms, packages, and driver operations: docs/day-to-day.md. Sanitized samples: docs/examples/.

Safety

• Show the plan before you write. vault.diff, then vault.deploy --dry-run, then a human's yes, then --yes or --step.
• A production environment (tier=prd) requires --confirm <env>, a committed tree, and a vault that matches the last recorded deploy. If it does not, --capture-drift records the vault's current state first.
• The deployer refuses to delete a driver unless you pass --delete-driver, and refuses to empty every object of a kind (entitlements, forms, PRDs, …) unless you pass --delete-all <kind>. A plan full of deletes usually means the tree is stale: re-import with import-live.
• Secrets stay in secrets-<env>.properties or come from a keychain, a command, or an environment variable. The tool prints names, never values. Do not paste passwords, snapshots, or client policy content into chat.
• driver.stop leaves the cache in place, and events keep queueing. driver.cache clear prints the count and the first and last event, writes them to a snapshot, and on staging or production also requires --confirm <env>.
• Edit operations refuse rather than leave the tree invalid. Do not pass --force to skip a refusal; fix the cause.

Guides

Start at docs/README.md. The short path:

1. Getting started — client tree, environments file, first import.
2. Tree layout — what driverset.xml, drivers/, cases/, and the secrets files are.
3. Day to day — policy change, deploy, packages, forms, operate.
4. Examples — fictional, sanitized snippets.
5. Agent guide — the same loop, written for an agent at the shell.

On a new machine, agent-assisted setup hands the install to a coding agent. Building from source by hand is docs/install.md.

Status

Phases 0–7, JSON provisioning forms, and workflow authoring (flow.*) are built. Vault deploy, driver operations, and Identity Applications proofs have been run on lab vaults. The phase-by-phase record, the architecture, and the decisions already made are in docs/plan.md. Release notes are CHANGELOG.md. Design notes under docs/ that still say "building" are historical; the commands in bin/idm are what shipped.

Install and build

A coding agent can do this setup from docs/agent-assisted-setup.md. The steps below are the same work by hand.

JDK 21, Maven 3.9 or newer, and the Identity Manager engine jars copied into a real lib/ directory (proprietary, never committed). A symlink of lib/, or symlinks of the jars, is not enough for Maven's file check. Build the DirXML Policy Simulator first so dirxml-simulator resolves from ~/.m2. bin/idm finds JDK 21 via IDM_JAVA_HOME (or java_home -v 21 on macOS), compiles on first use if target/classes is missing, and puts the simulator jar on the classpath (IDM_SIM_VERSION selects another installed version).

export IDM_JAVA_HOME=/path/to/jdk-21
mvn test
bin/idm

Windows: bin\idm.cmd. Step-by-step, including the engine jars and a client environments.properties: docs/install.md.

bin/idm doctor checks JDK 21, the simulator jar, and lib/*.jar. GitHub Actions does not have those jars. The default test job runs mvn -B -Pidm.portable test (doctor and the agent write gate). The full mvn test runs locally once lib/ and the simulator are installed, or in Actions when RUN_ENGINE_TESTS=true on a runner that has them. A CLI write also needs IDM_AGENT_ALLOW_WRITE=1 or --confirm <env>. Details: docs/install.md §2.4.

This repository

Path	What it is
bin/idm, bin/apps	The CLI and the Identity Applications helper
src/	Model, as-code, validate, edit, simulate, deploy, operate
docs/	User guides, then design notes and spikes
docs/agents.md, docs/agent-guide.md	How any agent runs the loop
mcp/dirxmldev-mcp/	Optional MCP server over a subset of bin/idm (docs/mcp.md)
.claude/skills/dirxml-dev/	The same loop, as a Claude Code skill
extensions/dirxmldev-visual/	Read-only policy-flow fishbone
DirXMLTraceViewer (separate repository)	The desktop trace viewer driver.trace view opens; viewer.install fetches it
lib/	Engine jars (gitignored)

Client trees, LDIFs, traces, environments.properties, and secrets*.properties stay in the client's repository. They are gitignored here.

For agents

The agent interface is the CLI. docs/agents.md is the setup for any product. docs/agent-guide.md is the loop and the refusals. A client repository should commit the AGENTS.md template so the agent that opens that repo sees the rules.

Claude Code also auto-loads .claude/skills/dirxml-dev/ when it runs in this checkout. That skill is a loader for the same instructions, not a second product. Copy or symlink it into a client repo's .claude/skills/ only when the agent is Claude Code.

Clients that call tools can run the optional MCP server in mcp/dirxmldev-mcp. It shells out to bin/idm. Reads and dry-runs are on by default. Vault deploy, rollback, and driver start/stop/cache clear stay off unless IDM_AGENT_ALLOW_WRITE=1 and the call sets confirm. Tree edits stay on the CLI. Details: docs/mcp.md.

Policy tests against sample events are the DirXML Policy Simulator. This repository is the loop around it.

License

The DirXMLDev source is MIT; proprietary NetIQ/OpenText engine jars and any third-party simulator packaging remain under their own terms and are not redistributed by this license.