Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/synthorg/api/controllers/agents.py`:
- Around line 185-190: The activity endpoint now hard-depends on
app_state.config_resolver.get_budget_config() which can raise and break timeline
rendering; wrap the await app_state.config_resolver.get_budget_config() call in
a try/except, and if it fails log a warning (including the exception) and set
currency = DEFAULT_CURRENCY before calling merge_activity_timeline; ensure you
still pass currency to merge_activity_timeline and keep
merge_activity_timeline/lifecycle_events/task_metrics usage unchanged so
timeline is rendered even when budget config fails.

In `@src/synthorg/api/controllers/departments.py`:
- Line 62: The health response always shows EUR because
_assemble_department_health never reads or passes the configured currency to the
builders; update _assemble_department_health to accept or retrieve the
department's configured currency (e.g., department.currency) and pass that value
into both the normal and degraded builders/constructors used in that function so
the currency Field (default or overridden) is honored; ensure you update calls
to _assemble_department_health and any builders used on both paths so the
configured currency flows into the response.

In `@src/synthorg/budget/_optimizer_helpers.py`:
- Line 13: The downgrade recommendation and other optimizer strings still
hardcode USD-style "$.../1k" output; update _build_downgrade_recommendation to
use the existing format_cost(...) helper so amounts are rendered in the
configured currency (e.g. produce f"{format_cost(unit_cost)}/1k" instead of
"$.../1k"). Likewise, replace the other hardcoded "$.../1k" constructions
referenced (around the earlier anomaly-description builders at the blocks
flagged near lines 118-119, 149-152, 186-189) to call format_cost(...) and
append "/1k" where appropriate so all cost strings use format_cost consistently.
Ensure you import/retain format_cost (already present) and only change the
string assembly in the functions that emit the per‑1k cost text, including
_build_downgrade_recommendation.

In `@src/synthorg/budget/config.py`:
- Around line 202-208: The BudgetConfig currency Field currently defaults to
"EUR", which breaks backward compatibility; change the default value for the
BudgetConfig.currency Field back to "USD" (leave min_length, max_length,
pattern, and description intact) so any code constructing BudgetConfig() before
runtime settings will continue to display USD by default.

In `@src/synthorg/budget/cost_record.py`:
- Line 30: The docstring for the cost_usd field incorrectly says "configured
currency"; update the descriptions at the cost_usd declarations (references to
cost_usd in this module) to say "base currency" or "USD (base currency)" to
match the persisted field name and behavior; ensure both occurrences (the field
docstring and any comment at its usage) reflect that no conversion is performed
and keep the symbol name cost_usd unchanged.

In `@src/synthorg/budget/currency.py`:
- Around line 52-73: The formatter currently assumes 2 decimals for all
currencies not in ZERO_DECIMAL_CURRENCIES, which misrenders ISO 4217 currencies
with 3 minor units (e.g. BHD, KWD, OMR); fix by adding explicit minor-units
metadata (e.g. a MINOR_UNITS: dict[str, int] mapping) and use that mapping when
formatting amounts instead of the binary ZERO_DECIMAL_CURRENCIES check, or
alternatively enforce config validation to only accept currencies supported by
the formatter (0 or 2 decimal currencies). Update uses of
ZERO_DECIMAL_CURRENCIES and any formatting/validation code that references it to
consult MINOR_UNITS (default to 2 if missing) or to reject unsupported
currencies so formatting is correct.
- Around line 15-16: DEFAULT_CURRENCY is hardcoded to "EUR", which forces
format_cost and format_cost_detail to default to euros; change DEFAULT_CURRENCY
to use the canonical system default instead (e.g., replace the literal "EUR"
with the shared system default constant or a call like
get_system_default_currency()) so the shared formatter inherits the app-wide
default currency; update imports/usage accordingly and ensure format_cost and
format_cost_detail continue to reference DEFAULT_CURRENCY.

In `@src/synthorg/budget/optimizer_models.py`:
- Around line 316-317: The docstring for budget_remaining_usd (and other *_usd
fields in this module) incorrectly says "configured currency" — update those
field docs to state that values are in the base currency (USD) unless explicitly
converted for display; search for budget_remaining_usd and any other *_usd names
(e.g., budget_spent_usd, budget_total_usd) in optimizer_models.py and change
their descriptions to say "value in base currency (USD) unless converted" rather
than "configured currency."

In `@src/synthorg/budget/trends.py`:
- Around line 74-75: The docstring language for projected_spend_usd (and other
*_usd occurrences) is misleading because these fields are computed/stored in
base USD with no conversion path; update the descriptions in the docstring(s)
referencing projected_spend_usd, any other "*_usd" fields, and the display-only
scope (lines around the Projected cumulative spend comment and the occurrences
at Line 83 and Line 378) to clearly state these values are in base currency
(USD) and are not converted—e.g., "Projected cumulative spend for this day,
expressed in base currency (USD); no currency conversion is performed
(display-only)". Ensure references to cost_usd and other *_usd variables are
consistent with that wording.

In `@src/synthorg/communication/message.py`:
- Line 43: The field cost_usd in the Message model has conflicting semantics
(doc says "configured currency" but name implies USD); change the model to use
currency-agnostic fields: replace cost_usd with cost_amount: float and add
cost_currency: str on the Message class (and any constructor/factory like
from_dict/serialize helpers), then provide a backwards-compatible deprecated
alias property/method cost_usd that returns cost_amount only when cost_currency
== "USD" (or raises/logs a deprecation warning otherwise) so consumers using
cost_usd get deterministic behavior while new code uses cost_amount +
cost_currency.

In `@src/synthorg/engine/agent_state.py`:
- Around line 28-29: The docstring/description for accumulated_cost_usd is
wrong: it refers to "configured currency" but the field is sourced from
context.accumulated_cost.cost_usd and is stored as USD/base currency. Update the
two descriptions (the one near accumulated_cost_usd and the duplicate at the
other occurrence) to state that the value is in USD (base currency), not the
configured/display currency, and ensure any mention of "configured currency" is
removed or replaced with "USD (base currency)"; reference the
accumulated_cost_usd field and the context.accumulated_cost.cost_usd source when
making the change.

In `@src/synthorg/engine/assignment/models.py`:
- Around line 23-24: The docstring now says the amount is in the configured
currency but the field name total_cost_usd still implies USD; update the model
to avoid confusing API consumers by either renaming the field to total_cost and
adding a deprecated alias total_cost_usd that maps to the new field, or if you
must keep the name for compatibility, add a clear comment above total_cost_usd
stating it is retained for backward compatibility and its value is in the
configured currency; modify any serialization/validation logic in the same
module (e.g., where total_cost_usd is referenced) to support the alias/rename so
external contracts remain stable.

In `@src/synthorg/engine/coordination/models.py`:
- Around line 178-182: The field name total_cost_usd contradicts its
description; rename the model field to total_cost: float = Field(default=0.0,
ge=0.0, description="Total cost in configured currency") and preserve backward
compatibility by providing a deprecated compatibility alias: implement a
read-only property or attribute named total_cost_usd that returns
self.total_cost and emits a deprecation warning when accessed, and enable
Pydantic population by field name (Config.allow_population_by_field_name = True)
so incoming payloads using the old key can still be accepted (or alternatively
set alias='total_cost_usd' on the new total_cost field if you prefer to accept
the old name on input); update relevant tests/docs accordingly.

In `@src/synthorg/engine/loop_protocol.py`:
- Line 48: The doc for the field cost_usd is now misleading because it documents
configured currency instead of USD; update the API to avoid ambiguity by
introducing a new field (e.g., cost or cost_configured) to hold the
configured-currency amount and revert cost_usd to always represent a
USD-denominated value (or deprecate cost_usd and keep it as an alias for
backward compatibility). Concretely: add the new field name to the data model in
loop_protocol.py, update docstrings/comments for both cost_usd and the new
field, implement serialization/deserialization compatibility so incoming
payloads with the old key map to the new field or are converted to USD if a
conversion rate is available, and mark cost_usd deprecated if you choose the new
field route; reference the cost_usd symbol and the new field name (cost or
cost_configured) when making these changes so consumers can be updated
consistently.

In `@src/synthorg/engine/metrics.py`:
- Line 28: The docstring/description for the metric cost_per_task incorrectly
states "configured currency" while the metric value is populated from
result.total_cost_usd; either perform a conversion from USD to the configured
currency before assigning cost_per_task or, more simply, update the description
to reflect that cost_per_task is currently in USD (or base currency) to match
the data source. Locate the cost_per_task documentation in metrics.py and change
the wording to indicate USD/base currency (or implement conversion from
result.total_cost_usd to the configured currency prior to setting cost_per_task)
so the doc and the value are consistent.

In `@src/synthorg/hr/activity.py`:
- Around line 100-104: The function _task_metric_to_activity currently hardcodes
currency="EUR"; import and use the shared DEFAULT_CURRENCY constant instead
(replace the default param and any literal "EUR" usages) so callers inherit the
global default; apply the same change to the other functions that hardcode EUR
referenced in the diff (the functions around the ranges 142-146 and 229-238) by
updating their default parameters and any string formatting to use
DEFAULT_CURRENCY and ensure DEFAULT_CURRENCY is imported at the top of
src/synthorg/hr/activity.py.

In `@src/synthorg/hr/performance/models.py`:
- Line 63: TaskMetricRecord.cost_usd and LlmCalibrationRecord.cost_usd still use
the legacy "_usd" suffix while their Field descriptions refer to the "configured
currency"; preserve the field names for API compatibility but update each Field
description to explicitly state this is a legacy "_usd" named field whose
numeric value is in the configured currency, and add a short note to the
migration documentation explaining the legacy naming tradeoff and where
consumers should map/rename the field; update descriptions on both symbols and
add the migration note referenced for lines 258-260.

In `@src/synthorg/hr/performance/summary.py`:
- Around line 74-78: The field name cost_per_task_usd is inconsistent with the
new "configured currency" description; update the model by adding a new alias
field cost_per_task that maps to the same value (same Field config:
default=None, ge=0.0, same description but referencing configured currency) and
mark cost_per_task_usd as a legacy/compatibility field by updating its
description to say "legacy name retained for API compatibility; value is in
configured currency" (or make cost_per_task_usd an alias to cost_per_task),
ensuring both names reference the same underlying value so consumers can use
either; also add a short note to the changelog/migration docs about the naming
discrepancy.

In `@src/synthorg/persistence/repositories.py`:
- Line 162: The repository docstring/contract text claiming "configured
currency" is inaccurate because aggregate() currently sums cost_usd records with
no conversion; update the wording to indicate the total is returned in the base
currency (e.g., "total cost in USD" or "total cost in base currency") so the
contract matches the implementation, and keep this aligned with the aggregate()
method and any repository-level conversion logic if added later.

In `@src/synthorg/providers/base.py`:
- Around line 339-342: The docstring for cost_per_1k_input and
cost_per_1k_output must explicitly state these rates are expressed in the
internal/base currency (not the user/display currency) because compute_cost()
populates TokenUsage.cost_usd in that same base currency; update the text around
cost_per_1k_input and cost_per_1k_output in the compute_cost() docstring (and
any related docstring for TokenUsage.cost_usd) to clearly say "per 1,000 tokens
in the internal/base currency (the currency used to populate
TokenUsage.cost_usd)" so callers understand the currency semantics.

In `@src/synthorg/providers/models.py`:
- Line 22: The docstring for TokenUsage.cost_usd incorrectly states “configured
currency” while the field is named cost_usd and there is no conversion logic;
either revert the description to state this is an estimated cost in USD (base
currency) or add an explicit new field (e.g., cost_display or
cost_in_configured_currency) plus conversion logic where TokenUsage objects are
constructed; update the docstring for TokenUsage.cost_usd (and the similar note
at the other occurrence) to match the chosen approach and reference the token
usage construction site/function so the conversion is implemented where tokens
are tallied.

In `@src/synthorg/providers/routing/models.py`:
- Around line 16-17: The model cost fields cost_per_1k_input and
cost_per_1k_output are defined without a fixed currency, but the routing logic
compares remaining_budget directly to their sum; fix by treating
cost_per_1k_input/cost_per_1k_output as base-currency amounts and convert any
display-currency remaining_budget into the same base currency before comparisons
(or store/require remaining_budget in base currency). Update every place that
does comparisons or arithmetic with remaining_budget and these cost fields
(where remaining_budget is compared to cost_per_1k_input + cost_per_1k_output)
to call the currency conversion helper (e.g., convert_to_base_currency(amount,
currency) or the existing exchanger utility) so the comparison is always done in
the base currency. Ensure constructor/serialization notes for the model document
that costs are base-currency values and add validation/tests for conversion in
the affected methods.

In `@src/synthorg/settings/definitions/budget.py`:
- Around line 136-149: The SettingDefinition for the budget currency currently
sets default="EUR", which changes registry default; update the SettingDefinition
(namespace=SettingNamespace.BUDGET, key="currency") to use default="USD" so
fresh installs and deployments without budget.currency override retain USD as
the registry default; keep the rest of the fields (description,
validator_pattern, yaml_path, group) unchanged.

In `@tests/unit/budget/test_config.py`:
- Around line 325-356: Consolidate the multiple rejection tests
(test_currency_lowercase_rejected, test_currency_too_short_rejected,
test_currency_too_long_rejected, test_currency_numeric_rejected,
test_currency_empty_rejected) into a single pytest.mark.parametrize test that
iterates invalid currency values and asserts that BudgetConfig(currency=value)
raises ValidationError; this reduces repetition while preserving each
invalid-case assertion.

In `@tests/unit/settings/test_resolver.py`:
- Around line 356-357: The test currently asserts the default currency as "EUR"
for the ("budget","currency") key (and the other occurrence noted) but Issue
`#810` requires the default be "USD"; update the assertions and any test fixtures
in test_resolver.py that set or expect ("budget","currency") to use "USD"
instead of "EUR" (including the other mentioned occurrence) and run the unit
tests to ensure no other tests rely on the old default.

In `@web/src/stores/settings.ts`:
- Around line 14-26: The store currently defaults currency to 'EUR' and swallows
fetch errors; change the initial currency value in useSettingsStore from 'EUR'
to 'USD' and update fetchCurrency to log failures and invalid values instead of
silently ignoring them: when calling settingsApi.getNamespaceSettings('budget')
handle the catch by logging the error (e.g., console.error or the project
logger) and do not change the store on failure, and when currencyEntry exists
but fails CURRENCY_PATTERN.log a warning indicating the invalid value; keep the
successful set({ currency: ... }) behavior in fetchCurrency so valid settings
still override the default.

In `@web/src/utils/format.ts`:
- Around line 39-41: The default currency for formatCurrency changed to 'EUR'
but must remain backward-compatible with 'USD'; restore the default parameter in
export function formatCurrency(value: number, currencyCode: string = 'USD') so
callers that omit currencyCode (or render before settings hydrate) continue to
show USD, and ensure any tests/uses relying on the old default still pass.
- Around line 43-51: The Intl.NumberFormat call in web/src/utils/format.ts is
forcing minimumFractionDigits and maximumFractionDigits which breaks ISO 4217
currency precision (e.g., JPY); remove the minimumFractionDigits and
maximumFractionDigits options from the Intl.NumberFormat instantiation so the
formatter uses each currency's native minor-unit rules, keep the try/catch and
fallback `${currencyCode} ${value.toFixed(2)}` as-is, and update any tests
(notably the one around line 113 expecting 4 decimals for 0.0001 USD) to reflect
the new default currency precision behavior.

---

Outside diff comments:
In `@src/synthorg/budget/optimizer.py`:
- Around line 632-636: The routing suggestion string in
synthorg.budget.optimizer.py uses a hardcoded "$" when formatting costs; update
this message to use the project's currency formatter (e.g., format_cost) instead
of "$". Replace the interpolations that use current_resolved.total_cost_per_1k
and candidate.total_cost_per_1k so they are passed through format_cost (keeping
the same precision/notation behavior) and build the message using most_used and
candidate.model_id as before; ensure the final string reads the same but without
any hardcoded USD symbol.

In `@src/synthorg/engine/parallel_models.py`:
- Around line 217-224: The property total_cost_usd aggregates
result.total_cost_usd but its description claims "configured currency," causing
a units mismatch; update the metadata/description for total_cost_usd to
explicitly state USD (e.g., "Total cost in USD across all agents") so the name
and description align, or alternatively rename the property to a
currency-agnostic identifier (e.g., total_cost) and change the aggregation to
use a currency-configured value (from each o.result) consistently; locate the
total_cost_usd property and adjust the description string or rename the property
and its usages accordingly.

In `@src/synthorg/engine/prompt.py`:
- Around line 140-165: Replace the hardcoded currency default "EUR" with the
repository constant DEFAULT_CURRENCY for this function's currency parameter and
for every other currency default in this file (including format_task_instruction
and the occurrences around lines referenced in the review). Update the function
signatures' default value from "EUR" to DEFAULT_CURRENCY, ensure
DEFAULT_CURRENCY is imported or referenced from its defining module, and run
tests/linters to confirm no unresolved names remain.

In `@src/synthorg/engine/run_result.py`:
- Around line 77-82: The property total_cost_usd currently returns
execution_result.context.accumulated_cost.cost_usd but its decorator description
says "Total cost in configured currency", causing a doc/contract mismatch;
update the decorator description to accurately state "Total cost in USD" (or
similar explicit USD wording) so the documented semantics match the actual
return value of total_cost_usd, leaving the property name and returned field
(execution_result.context.accumulated_cost.cost_usd) unchanged.

In `@web/src/__tests__/utils/format.property.test.ts`:
- Around line 5-25: Add a property-based test that verifies
formatCurrency(value) (call with no currencyCode) uses the default currency
(expected USD per Issue `#810`) by asserting the output contains '$'; locate and
modify the tests near the existing formatCurrency tests in
format.property.test.ts (the existing USD and EUR tests reference
formatCurrency) and add a new it(...) using fc.assert/fc.property with similar
double generation to assert formatCurrency(value) contains '$'.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@docs/design/engine.md`:
- Line 96: The phrase "in configured currency" on the budget_limit field is
misleading; update the description for budget_limit to state that the value is
stored as a base-currency numeric limit (no runtime currency conversion) and is
only rendered using the configured currency formatting for display; explicitly
mention budget_limit remains in base currency and that any displayed
symbol/formatting is presentation-only so readers know there's no semantic
conversion.

In `@src/synthorg/api/controllers/activities.py`:
- Around line 142-150: Wrap the call to
app_state.config_resolver.get_budget_config() in a try/except to mirror
agents.py: on exception log a warning (include the exception) and fall back to a
sensible default budget config before calling merge_activity_timeline; update
the variable budget_cfg accordingly so merge_activity_timeline(...) still
receives a valid currency and other fields even if config resolution fails.

In `@src/synthorg/api/controllers/budget.py`:
- Line 24: The controller mixes the DEFAULT_CURRENCY constant with hardcoded
"USD" in response DTO defaults, causing divergent API contracts; update all
places in this file (e.g. _build_summaries(), any response DTO default values)
to use the single shared constant synthorg.budget.currency.DEFAULT_CURRENCY
instead of literal "USD", or alternatively make the DTOs require currency so
missing values fail fast—replace every hardcoded "USD" occurrence in this module
(including the sections noted around lines ~50-55, ~77-82, ~112-117, ~162-167,
~188-191) with DEFAULT_CURRENCY and ensure _build_summaries() and the response
model definitions reference that single symbol.
- Around line 40-56: The API is exposing a misleading payload where
total_cost_usd remains in USD while the currency field can be a different
configured value; update the model fields (e.g., the Pydantic Field named
currency and any similar fields that pair with total_cost_usd/cost_usd) to make
the public contract explicit by renaming currency to display_currency (or
similar) and adjusting its Field description to state "display-only; no
conversion performed" (also update any docstrings mentioning "in configured
currency"), and propagate the renaming/description change to all corresponding
usages (places noted around the other occurrences) so clients cannot assume an
amount conversion is implied.

In `@src/synthorg/api/controllers/departments.py`:
- Around line 63-69: DepartmentHealth currently hardcodes the currency default
as "USD"; change it to reuse the existing DEFAULT_CURRENCY constant to avoid
duplicate defaults. Update the Field for the currency attribute in the
DepartmentHealth model to set default=DEFAULT_CURRENCY (and add/import
DEFAULT_CURRENCY at top of the module if not already present) so the model and
helper functions share the same source of truth.

In `@src/synthorg/api/dto.py`:
- Around line 478-484: Several instantiations of CoordinationResultResponse are
relying on the Field default "USD" and must be made explicit; find every new
CoordinationResultResponse(...) call (including the ones in the controller and
unit tests) and add an explicit currency argument (e.g.
currency=runtime_currency or currency=settings.DEFAULT_CURRENCY) so the
runtime/configured currency is passed rather than silently using the model
default; update the five missing call sites and adjust test expectations in
test_dto to assert the explicit currency value.

In `@src/synthorg/budget/cost_tiers.py`:
- Around line 50-56: The Field descriptions for price_range_min and
price_range_max are ambiguous about currency units; update their descriptions to
explicitly state these values are in the system's base currency (not a
displayed/converted currency), e.g. reference price_range_min and
price_range_max and mention "base currency" or "base-currency units" and clarify
that None for price_range_max = unbounded; keep the numeric constraints (ge=0.0)
unchanged and ensure wording is consistent between both Field descriptions.

In `@src/synthorg/budget/currency.py`:
- Around line 12-15: Import and use the module-level structured logger and the
budget observability event constant, then log validation failures at WARNING
with context before raising: add e.g. "from synthorg.logging import logger" (or
your project's logger import) and "from synthorg.budget.observability.events
import BUDGET_INVALID_COST_FORMAT" at the top of the module, and inside
format_cost (and the other validation block around lines 135-140) replace direct
raises with a logger.warning call that includes the event constant and
contextual fields (e.g. value, value_type, formatter) and then re-raise the same
exception; ensure the log message uses structured kwargs
(event=BUDGET_INVALID_COST_FORMAT, cost=value, reason='invalid_formatter' or
similar) so every validation error is logged before raising.

In `@src/synthorg/budget/tracker.py`:
- Line 136: The docstrings saying "Rounded total cost in configured currency"
are incorrect because the methods return aggregated cost_usd without conversion;
update the two docstrings (the one containing the string "Rounded total cost in
configured currency." and the other docstring at the second occurrence) to state
that the returned units are the base currency (cost_usd / USD) and not the
configured display currency, and optionally add a note that conversion is not
performed in this class so callers must convert if needed.

In `@src/synthorg/config/schema.py`:
- Around line 63-72: The descriptions for the configuration fields
cost_per_1k_input and cost_per_1k_output are ambiguous about currency; update
their Field description strings in the schema (cost_per_1k_input and
cost_per_1k_output in src/synthorg/config/schema.py) to explicitly state the
expected currency (e.g., "Cost per 1k input tokens (USD)" and "Cost per 1k
output tokens (USD)") so they clearly match the downstream result.total_cost_usd
base-currency behavior, or alternatively indicate they follow budget.currency if
you choose that design—pick one policy and make the wording explicit for both
fields.

In `@src/synthorg/hr/performance/models.py`:
- Line 63: The Field descriptions for the cost fields are missing the "in USD
(base currency)" clarification; update the cost_usd Field description in
TaskMetricRecord and LlmCalibrationRecord to match their class docstrings (e.g.,
change description="Cost of the task" / "Cost of the LLM call" to include "in
USD (base currency)") so the OpenAPI/JSON schema is authoritative and consistent
with the docstrings; locate the cost_usd Field declarations in TaskMetricRecord
and LlmCalibrationRecord and modify their description text accordingly.

In `@src/synthorg/providers/capabilities.py`:
- Around line 26-27: The docstrings for the cost fields removed the currency
unit and must be restored: update the documentation for cost_per_1k_input and
cost_per_1k_output (and the additional occurrences at the other two locations)
to explicitly state the base currency (e.g., "in USD" or the project's
configured base currency) and clarify "per 1,000 tokens"; locate the fields by
the identifiers cost_per_1k_input and cost_per_1k_output in
src/synthorg/providers/capabilities.py and change their descriptions to include
the base-currency wording so downstream routing/budget arithmetic is
unambiguous.

In `@web/src/__tests__/utils/format.test.ts`:
- Around line 100-104: The JPY test for formatCurrency currently only checks for
the yen sign and thousands separator, so it would still pass if fractional
digits are present; update the 'formats JPY values' test (the one calling
formatCurrency(1000, 'JPY')) to assert that the formatted string omits
fractional digits by ensuring it does not contain a decimal point or any
fractional portion (for example assert it does not contain '.' or '.00', or use
a regex to match exactly no decimal fraction), so the test fails if
formatCurrency regresses to producing "¥1,000.00".

In `@web/src/utils/format.ts`:
- Around line 43-50: The fallback currently always uses value.toFixed(2) and
thus ignores zero-decimal currencies; update the catch path to use the same
minor-unit logic as the normal formatting code instead of hardcoding 2 decimals:
compute the number of fraction digits for currencyCode (reuse the existing
minor-units lookup or helper used elsewhere in this file, e.g.,
CURRENCY_MINOR_UNITS or getCurrencyMinorUnits) and call
value.toFixed(minorUnits) in the return so JPY/KRW fall back to no decimals.
Ensure you reference currencyCode and value in the catch block and keep the
error log as-is.

---

Outside diff comments:
In `@src/synthorg/api/controllers/analytics.py`:
- Around line 594-602: ForecastResponse.currency is never set in the
/analytics/forecast response so it always appears as USD; update the code that
constructs ForecastResponse (the ForecastResponse(...) call in this file) to
populate the currency field from the configured budget currency (the same source
used by /analytics/overview, e.g. budget_cfg.currency or the variable holding
the configured currency) so the returned ForecastResponse.currency matches the
configured currency.

In `@src/synthorg/core/company.py`:
- Around line 464-484: Update the budget_monthly Field docstring to state that
the value is stored and compared in the system base currency (USD) rather than
the configured currency; specifically change the description on the
budget_monthly Field (the Field with default=100.0, ge=0.0) to mention "base
currency (USD)" so it matches how costs are calculated (see tracker calculation
using total_cost / budget_monthly) and the project policy in budget/currency.py;
leave the default value as-is.

In `@src/synthorg/engine/task_engine_models.py`:
- Around line 61-90: The Task model's budget_limit Field description incorrectly
says "configured currency" but is compared against ctx.accumulated_cost.cost_usd
and enforcer budget checks in the runtime, so update the Field description for
budget_limit in task_engine_models.Task to indicate base currency (e.g.,
"Maximum spend in base currency (USD)") so documentation matches the USD
comparisons in loop and enforcer logic.

---

Duplicate comments:
In `@src/synthorg/hr/performance/summary.py`:
- Around line 39-40: The docstring/field description inconsistency for the field
cost_per_task_usd must be fixed: update both occurrences so they explicitly
state the unit and that values are in USD (base currency) and the window
fallback (30d, falling back to 7d) to match the `_usd` naming semantics; locate
the field description for cost_per_task_usd in the summary dataclass/module and
make both the earlier description (currently mentioning USD) and the later one
(currently missing unit) identical and explicit about "USD (base currency)" and
the 30d/7d window.

In `@src/synthorg/providers/routing/models.py`:
- Around line 16-17: Docstring and comparison ambiguity: cost_per_1k_input and
cost_per_1k_output must be documented and used as base-currency amounts per
1,000 tokens so they are not mixed with remaining_budget. Update the field docs
for cost_per_1k_input and cost_per_1k_output to explicitly state "amount in base
currency per 1,000 tokens", and change any numeric comparisons that use
remaining_budget (e.g., the logic that checks remaining_budget vs
cost_per_1k_input + cost_per_1k_output) to convert token-based costs into
base-currency totals before comparing—compute actual_cost = (tokens_needed /
1000) * (cost_per_1k_input + cost_per_1k_output) or normalize remaining_budget
into a per-1k-token equivalent, then compare using the normalized values; ensure
variables referenced include cost_per_1k_input, cost_per_1k_output, and
remaining_budget so the change applies everywhere those names are used.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/synthorg/api/controllers/analytics.py`:
- Around line 166-172: The backend ForecastResponse Pydantic model defines a
currency field (see currency: str = Field(...)); update the corresponding
TypeScript ForecastResponse interface to include currency: string so frontend
types match the backend and consumers get type checking and formatting support
for ISO 4217 currency codes.

In `@src/synthorg/budget/_enforcer_helpers.py`:
- Around line 135-153: The _ALERT_LEVEL_ORDER dict is mutable after import which
allows later corruption; change the code to build the mapping into a temporary
plain dict, run the existing validation checks against that temp (checking keys
and unique values), then wrap and assign the final name _ALERT_LEVEL_ORDER using
types.MappingProxyType(temp) so external code cannot mutate it; reference the
symbol _ALERT_LEVEL_ORDER and the enum BudgetAlertLevel when making these
changes and add the import for MappingProxyType from the types module.

In `@src/synthorg/core/role.py`:
- Around line 40-41: The docstring for Authority.budget_limit incorrectly states
the limit is in the "configured currency"; update the wording to make clear the
budget_limit is expressed in the system base currency (not converted by
configured/display currency) and that configured currency only affects
formatting/display. Locate the Authority class docstring and any parameter
descriptions referencing budget_limit (e.g., "budget_limit: Maximum spend per
task in configured currency") and replace with text like "budget_limit: Maximum
spend per task in base currency; configured currency is used only for
display/formatting." Ensure the same clarification is applied to the other
occurrence(s) of this wording in the file (the second budget_limit description).

In `@src/synthorg/core/task.py`:
- Around line 66-67: The docstring for Task.budget_limit incorrectly says
"configured currency"; update the wording to state this field is a base-currency
numeric limit (i.e., enforced in base currency, not converted), so change
occurrences in the Task class docstring and the parameter description for
budget_limit to mention "base currency" or "base-currency numeric limit" and
that the value is a numeric limit in the system's base currency; locate
references to Task.budget_limit and adjust both places where "configured
currency" appears.

In `@src/synthorg/providers/routing/models.py`:
- Around line 16-19: The docstring for the token cost fields is redundant:
update the descriptions for cost_per_1k_input and cost_per_1k_output to remove
the duplicated "per 1,000 tokens" phrase so each reads clearly (e.g., "Cost per
1,000 input tokens in USD (base currency)." and similarly for output). Locate
the fields cost_per_1k_input and cost_per_1k_output in models.py and replace the
current lines with the simplified phrasing.

In `@src/synthorg/templates/schema.py`:
- Around line 316-317: Update the docstring for the budget_monthly field to
state that amounts are in the base currency (not a runtime/conversion currency)
— replace phrases like "configured currency" with "base currency" in the
budget_monthly documentation (and the surrounding docstring block that spans the
autonomy/budget description), e.g., adjust the docstring in the schema where
budget_monthly is defined so it clearly reads "Default monthly budget in base
currency" and make the same wording change in the related docblock that
currently covers lines ~346-350.

In `@tests/unit/budget/test_enforcer.py`:
- Around line 160-174: Combine the two tests into one parametrized pytest test
that covers both the default and custom currency cases: call the test e.g.
test_currency_returns_configured_or_default and parametrize over inputs (a
BudgetConfig built with no currency and one with currency="GBP") and expected
outputs (use DEFAULT_CURRENCY for the default case instead of the hardcoded
"USD"). Instantiate BudgetEnforcer with BudgetConfig and CostTracker (symbols:
BudgetEnforcer, BudgetConfig, CostTracker) and assert enforcer.currency equals
the expected value; import DEFAULT_CURRENCY from the module that defines it and
reference that symbol in the expected values.

---

Outside diff comments:
In `@src/synthorg/budget/_optimizer_helpers.py`:
- Around line 258-343: Call _build_downgrade_recommendation with the configured
currency instead of relying on its DEFAULT_CURRENCY: find the call site in the
optimizer where _build_downgrade_recommendation(...) is invoked and add
currency=self._budget_config.currency to the arguments so the recommendation
reason uses the configured budget currency; ensure the symbol names
_build_downgrade_recommendation and self._budget_config.currency are used
exactly as shown.

In `@src/synthorg/hr/performance/models.py`:
- Around line 369-372: Update the docstring and the Field description to
explicitly state the currency is USD (base currency): modify the class docstring
referenced around line 350 and the Field for avg_cost_per_task (symbol:
avg_cost_per_task) so both read something like "in USD (base currency)" to match
the existing cost_usd field documentation; ensure any other cost-related Field
descriptions (e.g., cost_usd) remain consistent with this phrasing.

In `@src/synthorg/providers/routing/models.py`:
- Around line 93-100: The Field description for remaining_budget should
explicitly state that the value is in the same base currency as
total_cost_per_1k (USD); update the description on the remaining_budget Field
(the remaining_budget declaration) to mention "USD" (or "base currency (USD)")
and clarify it is a per-request cost ceiling compared against total_cost_per_1k
so callers know the unit matches.

---

Duplicate comments:
In `@src/synthorg/api/dto.py`:
- Around line 478-484: The DTO currently defaults currency to "USD" which masks
missing values; change the Field declaration for currency in
src/synthorg/api/dto.py to be required (use Field(...), remove default and
min/max/pattern can remain) so missing currency raises validation errors, and
update the mapper in src/synthorg/api/controllers/coordination.py to explicitly
supply the tenant/request currency when constructing the DTO (locate the mapping
function that omits the currency and add the currency argument from the
request/tenant context).

In `@src/synthorg/budget/currency.py`:
- Around line 135-140: Add structured logging immediately before raising the
ValueError checks that validate inputs in src.synthorg.budget.currency: when
checking math.isfinite(value) and when checking precision < 0, log a warning or
error with clear context (include the variable values `value` and `precision`
and the operation e.g. "formatting cost") using the module logger (e.g., logger
= logging.getLogger(__name__) or existing module-level logger) and then raise
the ValueError as before so that both validation failures are logged with
context prior to raising.

In `@src/synthorg/config/schema.py`:
- Around line 50-51: Update the class/module docstring attributes for
cost_per_1k_input and cost_per_1k_output to match the Field descriptions by
explicitly indicating the currency context (e.g. "USD (base currency)"); locate
the docstring entries for cost_per_1k_input and cost_per_1k_output in schema.py
and amend their text to include the same "USD (base currency)" wording used in
the corresponding Field(...) descriptions so docs are consistent.

In `@src/synthorg/providers/base.py`:
- Around line 339-342: Docstring lacks explicit base-currency semantics: update
the compute_cost() docstring (in the provider base class) to state that
cost_per_1k_input and cost_per_1k_output are expressed in USD per 1,000 tokens
(finite and >= 0) and that implementations must compute and populate
TokenUsage.cost_usd in USD using those rates; also clarify any
rounding/aggregation behavior expected when converting per-1k rates to actual
token counts so implementers know how to derive cost_usd from input_tokens and
output_tokens.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/synthorg/api/controllers/budget.py`:
- Around line 301-307: The current sequential awaits for
app_state.config_resolver.get_budget_config(),
app_state.cost_tracker.get_records(...), and
app_state.cost_tracker.get_agent_cost(...) in get_agent_spending() add avoidable
latency; run the independent get_budget_config() in parallel with the tracker
calls using an asyncio.TaskGroup: spawn tasks for get_budget_config(),
get_records(agent_id, task_id) and get_agent_cost(agent_id) (or the exact two
tracker calls referenced around lines 339-345), await them all, then pass the
resolved currency and records into _build_summaries(); ensure you replace the
sequential awaits with the TaskGroup fan-out/fan-in pattern and use the task
results for currency, records, and agent cost.

In `@src/synthorg/api/dto.py`:
- Line 228: The budget_limit field needs an explicit Pydantic Field description
so the JSON schema/API docs show it represents USD; update the model's
budget_limit declaration to use Field(description="Maximum spend in USD (base
currency).") (and add/ensure the Field import from pydantic is present) so the
schema includes the description for clients.

In `@src/synthorg/budget/_enforcer_helpers.py`:
- Around line 143-153: The current validation only checks keys and uniqueness in
_raw_order/_ALERT_LEVEL_ORDER but not whether numeric values respect the
expected severity ordering used by _emit_alert; update the validation to enforce
monotonic severity order by iterating BudgetAlertLevel in its defined ordinal
order and verifying that the mapped integer values are strictly increasing (or
match a canonical ordinal mapping) for each successive member; if any value
violates the monotonic increase, raise a RuntimeError with a clear message
referencing _ALERT_LEVEL_ORDER and BudgetAlertLevel so incorrect swaps or
out-of-range assignments are rejected at import time.
- Line 253: The closure-local variable last_alert in _build_checker_closure() is
reset to NORMAL for every checker instance, causing repeated
BUDGET_ALERT_THRESHOLD_CROSSED emissions across tasks; move persistent state out
of the closure by storing the last-emitted BudgetAlertLevel on a shared object
(e.g., the Enforcer instance or the billing-period state) and have
_build_checker_closure() read/update that shared field instead of using the
local last_alert list so threshold crossings are deduplicated across tasks.
- Around line 37-106: The _apply_downgrade function is currently too long and
mixes multiple responsibilities. Refactor it by extracting smaller helper
functions to handle specific tasks: model resolution and associated skip
logging, alias-to-target lookup with logging, and the model identity update.
This will make each step easier to test and keep _apply_downgrade under 50 lines
as per the guideline.

In `@src/synthorg/hr/performance/models.py`:
- Around line 369-373: The field avg_cost_per_task on the Pydantic model is
inconsistent with other cost fields that use a _usd suffix; rename
avg_cost_per_task to avg_cost_per_task_usd (and update all references/usages,
e.g., in serializers, tests, and any code accessing the attribute) to match
cost_usd naming, or if API compatibility prevents renaming, add a clear code
comment above the Field explaining this intentional exception and keep the
current name; ensure the Field description remains "Average cost per task in USD
(base currency)" and update any related OpenAPI/type docs accordingly.

In `@tests/unit/budget/test_enforcer.py`:
- Around line 154-182: The currency-focused parametrized tests
(TestCurrencyProperty and its test_returns_configured_or_default) should be
moved out of the oversized tests/unit/budget/test_enforcer.py into a new
dedicated module (e.g., tests/unit/budget/test_enforcer_currency.py); copy the
TestCurrencyProperty class and any other currency cases referenced (also from
the block at lines noted around 237-260) into that new file, update imports so
BudgetEnforcer, BudgetConfig, CostTracker, and DEFAULT_CURRENCY are imported in
the new module, and leave the original file with those tests removed to keep it
under the 800-line guideline.

---

Outside diff comments:
In `@src/synthorg/api/controllers/analytics.py`:
- Around line 578-604: get_forecast currently calls
_resolve_budget_context(app_state, now=...) which reads budget config, and then
separately awaits app_state.config_resolver.get_budget_config() just to get
currency, causing redundant async access; fix by fetching budget_cfg once (await
app_state.config_resolver.get_budget_config()) before calling
_resolve_budget_context and either pass budget_cfg into _resolve_budget_context
(add an optional parameter) or have get_forecast extract the currency from the
budget object returned by _resolve_budget_context (e.g., budget.currency) and
remove the extra get_budget_config() call, updating references to
budget_cfg/currency accordingly.

---

Duplicate comments:
In `@src/synthorg/api/dto.py`:
- Around line 478-484: The DTO currently defaults currency to "USD" which masks
the resolved setting and can make total_cost_usd misleading; change the Field
for currency in the DTO (currency: str = Field(..., min_length=3, max_length=3,
pattern=r"^[A-Z]{3}$", description="ISO 4217 currency code")) so it is
explicit/required (remove the default), add or update the description for
total_cost_usd to state it is the amount in the system/base currency, and then
update the controller function that builds this DTO (the construction in
src/synthorg/api/controllers/coordination.py and the helper
_map_result_to_response()) to pass the resolved currency value explicitly when
instantiating the DTO.

In `@src/synthorg/core/task.py`:
- Line 66: Update the docstring for the budget_limit parameter to avoid
hardcoding "USD": change the description of budget_limit (in
src/synthorg/core/task.py, e.g., the Task or related function where budget_limit
is documented) to refer to the base currency generically and note that display
formatting follows budget.currency (for example: "Maximum spend for this task in
base currency (display formatting follows budget.currency)"). Ensure the same
wording change is applied to both occurrences referenced (around the
budget_limit doc at lines ~66 and ~124).