Write the second half of the documentation for imdUSD, a dollar-denominated CDP stablecoin in this repository: the contract reference for integrators, the governance and risk pages, and the monetary policy and evidence pages. Deliver Markdown files only; a separate step renders them into the site. Do not modify any tracked file.

BEFORE WRITING, research how strong protocol reference and risk documentation is organised (the Diataxis reference and explanation forms; live examples such as Liquity, Aave and MakerDAO/Sky technical and risk docs) and apply what you find. Summarise the practices you adopted, with links, in artifacts/docs/README.md.

PAGES IN THIS JOB AND WHAT EACH MUST COVER:

reference/contracts-and-addresses: the contracts deployed at launch, per docs/MAINNET-RUNBOOK.md section 6: SwarmRelay, Treasury, WorkOracleFactory, PriceFeed, NhiFeed, SpotFeed and ParameterizedVault, the ImdUSD, Parameters and UsdPriceFeed it creates, and SharePriceFeed and SwarmWorkOracle as the runbook uses them. For each: its role, what creates it, immutable versus governed values. Leave out test and retired contracts (MockIMD, MockWorkOracle, LaunchToken) and Registry, which nothing reads. Every address is "(waiting for mainnet launch)".

reference/vault-functions and reference/events-and-errors: every external function, event and custom error of ParameterizedVault, the deployed vault, including what it inherits from CDPVault, generated from source and docs/abi/, with what each requires and what each changes.

reference/oracle-and-question-binding: SwarmFeed, attestation v2 (EIP-712 domain, panel size, quorum, agreed), expectedQuestionHash and the pinned window span, the relayer, staleness and the deviation bound, and UsdPriceFeed.

reference/reading-state: how to read positions, backing and feeds; that a public RPC can return an empty log array for a range it declines, so position discovery must use an explorer fallback and treat "unreadable" as different from "none".

governance/parameters, governance/timelock-and-proposals, governance/network-health: every governed value, what bounds it and how it is changed, the propose, timelock, apply and cancel flow, and how the network health index sets mat and lull.

economics/monetary-policy: the issuance channels (draw against collateral, and earn against attested work within earnLine; whether earn is open at launch is (under consideration)), redemption pricing and fee shape, the stability fee (duty, accrued through chi), backing per unit and why it is capped at par, where protocol revenue goes.

economics/swarm-evidence: what the swarm attests and how strongly: panel sizes and agreement floors, question binding checked on chain against a live service-signed attestation, the work tally, and the parameter research in docs/RESEARCH-PARAMS-2026-10-04.md. Separate measured facts from recommendations, and present the research as analysis of the parameters, not as their values.

economics/risks-and-open-questions: oracle, collateral liquidity, governance, smart-contract and keeper risks, drawing on docs/INTERNAL-AUDIT-2026-10-04.md and the audits in docs/; what is proven on chain versus only in tests; the oracle budget and how updates are paid for, with TODO(oracle-funding) where the mechanism is not in source.

CONVENTIONS (shared with a sibling job writing the other half; follow exactly). Every page is Markdown at the path given, opening with a front-matter block: title, section, order (integer), audience (borrowers | keepers | integrators | governance | everyone), and sources (repo paths with line numbers, or URLs, that support the page). Describe imdUSD plainly as what it is and how it functions, from this repository's current source. Do NOT mention testnets, Sepolia, test deployments, version history or anything as "currently" or "today": these pages ship with the mainnet launch and must not need revising after it. Every contract address is written exactly as "(waiting for mainnet launch)". The stablecoin is imdUSD. Quote every contract, function, event and error identifier exactly as in source. The vault's verbs and parameters (lock, free, draw, wipe, bark, bite, heel, cash, earn, drip; mat, duty, line, chi, CHOP_PERCENT, chip, cut, tail, gap, lull, skew, wage, earnLine, earnMat) are a deliberate homage to MakerDAO, partly borrowed and partly coined in its spirit, recorded with their origins in docs/NAMING.md: use them for identifiers, explain each in plain words on first use, and give the homage one sentence in the overview. Users never see them: the terminal labels every action in plain words, so overview and guide pages name actions exactly as its buttons do (Deposit, Withdraw, Borrow, Repay, Redeem, Mark, Liquidate, Clear mark, Mint from work) and give the contract function once alongside in code format, for example "Borrow (draw)". Reference, governance and economics pages lead with the identifiers. Every economic parameter VALUE, governed or fixed, is written exactly as "(under consideration)": the mat curve, duty, line, CHOP_PERCENT and its split between chip and cut, the redemption fee floor, cap and decay, gap, lull and tail, skew, feed maximum age, earnMat, earnLine and wage, and every bound on them. Explain what each is and how it works, never its number. Oracle updates purchased on chain through an Intake contract and funded from treasury assets are being built and are not in this source: describe only what the source implements, and where a page needs that mechanism write a visible line "TODO(oracle-funding): …" stating what belongs there, for us to fill. AUTHORITY: src/.sol is the truth for how the protocol works. docs/NAMING.md, docs/MAINNET-RUNBOOK.md and the README describe it; the dated records in docs/ (AUDIT-, INTERNAL-AUDIT-, RESEARCH-PARAMS-, DOCS-JOB-A-*) describe the code as it was when written, so use them for evidence and risk, never for current behaviour. The whitepaper is a founding document, not a specification: do not use it as a source. Where anything disagrees with the code, follow the code and note it in your README. THE FIRST HALF IS ALREADY WRITTEN, in web/content/docs/ (overview, guides, keepers): read it first, use its terms and definitions, link to it rather than repeating it, and note any conflict with it in your README. Never invent an address, parameter value or function: read it from source or leave a visible TODO. Link between pages with relative paths, including into the sibling set listed below. Plain language, second person in guides, numbered steps for procedures, one idea per paragraph, units on every number, terms defined on first use. No marketing voice, no emoji.

FULL TABLE OF CONTENTS (both jobs): overview/what-is-imdusd, overview/how-it-holds-a-dollar, overview/glossary, guides/use-the-terminal, guides/open-a-position, guides/manage-and-protect-a-position, guides/redeem, keepers/how-liquidation-works, keepers/mark-and-liquidate, keepers/relay-oracle-updates, keepers/keeper-economics (job A); reference/contracts-and-addresses, reference/vault-functions, reference/events-and-errors, reference/oracle-and-question-binding, reference/reading-state, governance/parameters, governance/timelock-and-proposals, governance/network-health, economics/monetary-policy, economics/swarm-evidence, economics/risks-and-open-questions (job B).

DELIVERABLE: the eleven pages at artifacts/docs//.md, plus artifacts/docs/README.md stating sources used, practices adopted, every code-versus-doc disagreement found, and every TODO left.