release: 1.2.0

[ashleythedeveloper]

This PR ships the work accumulated on next since 1.1.0, releasing vckit 1.2.0. Highlights: a new DATABASE_SSL env var on the agent template, a hardened Docker entrypoint that fails loudly on did import errors (with SEED_DID=false opt-out), basePath derivation from API_DOMAIN, proper exit codes on all did CLI subcommands, and a @digitalcredentials/jsonld upgrade to 9.0.0.

See the CHANGELOG for the full list and ADRs 0001-0003 in docs/adr/ for the deployment-fix decisions.

Test plan

• All feature PRs merged into next passed their individual CI runs
• Release-please changelog PR (chore(release/1.2.0): release 1.2.0 #296) regenerated correctly after main was merged into the release branch (1.1.0 tag now in ancestry)
• CI on this PR runs pnpm build:agent and pnpm test:packages cleanly
• Release workflow tags 1.2.0 and creates the GitHub release after merge to main

[gemini-code-assist]

Code Review

This pull request implements several Docker deployment improvements, including deriving the OpenAPI basePath port from API_DOMAIN to support reverse proxies, adding a DATABASE_SSL environment variable for managed PostgreSQL, and hardening the DID seeding process with a SEED_DID toggle and mandatory error checking. It also updates the renderer package to use standardized IRIs and upgrades the jsonld dependency. Feedback focuses on improving the efficiency of the entrypoint script using shell redirection and adding safety checks when extracting template and URL data from JSON-LD structures to prevent potential runtime crashes.

[gemini-code-assist]

Reading the entire seed file into a shell variable and then piping it via printf is inefficient and can hit shell variable size limits for large DID documents. Using direct redirection is more robust and idiomatic.

Suggested change

	SEED_DATA=$(cat did-web-identifier.json) || { echo "ERROR: Failed to read did-web-identifier.json"; exit 1; }
	printf '%s' "$SEED_DATA" | node packages/cli/build/cli.js did import || { echo "ERROR: DID import failed (exit code $?)"; exit 1; }
	node packages/cli/build/cli.js did import < did-web-identifier.json || { echo "ERROR: DID import failed (exit code $?)"; exit 1; }

[gemini-code-assist]

The current extraction logic will throw an error if data[TEMPLATE_IRI] is an empty array (which can happen in some JSON-LD expansion scenarios), as it attempts to access [0]['@value'] without checking if the element exists. Using optional chaining or a length check is safer.

Suggested change

	const template = data[TEMPLATE_IRI]
	? (data[TEMPLATE_IRI] as { '@value': string }[])[0]['@value']
	const template = (data[TEMPLATE_IRI] as { '@value': string }[])?.[0]
	? (data[TEMPLATE_IRI] as { '@value': string }[])[0]['@value']

[gemini-code-assist]

Similar to the template extraction, this will crash if data[URL_IRI] is an empty array. A safety check for the first element should be added.

Suggested change

	const url = data[URL_IRI]
	? (data[URL_IRI] as { '@value': string }[])[0]['@value']
	const url = (data[URL_IRI] as { '@value': string }[])?.[0]
	? (data[URL_IRI] as { '@value': string }[])[0]['@value']

[gemini-code-assist]

This extraction logic is vulnerable to a crash if data[TEMPLATE_IRI] is an empty array. It should be hardened to check for the existence of the first element before accessing its properties.

Suggested change

	const template = data[TEMPLATE_IRI]
	? (data[TEMPLATE_IRI] as { '@value': string }[])[0]['@value']
	const template = (data[TEMPLATE_IRI] as { '@value': string }[])?.[0]
	? (data[TEMPLATE_IRI] as { '@value': string }[])[0]['@value']