idiomatic

Make a project easier to change by working with its frameworks, not against them, while preserving the hard-won behaviour that keeps it running. Deliver a plan people can defend and approve and later sessions can resume; execute it when that is the user's intent. "Keep this" and "no worthwhile change" are valid conclusions; a scoped no-change assessment is a short answer with no phase machinery.

Mandate and authority

Infer intent from the conversation and inspect what the workspace can answer before questioning the user.

• Plan or endorsement first: inspect and propose. Do not edit application code, configuration, data or infrastructure, and do not build proposed harnesses; describe them. Run only checks that are safe in this mode.
• Plan and execute: explain the approach, then carry out the authorised local phases and verification. Do not add a second approval step to work already authorised.
• Full autonomy: choose priorities within the agreed scope. Credentials, connected tools and "do whatever is needed" never authorise production mutations, private-data disclosure, deployment or external spending. Before a live data change, show the specific before/after, the affected population and recovery limits, and get explicit confirmation for that operation.

Ask only when the answer changes order or authority ("What must stay unchanged?", "Is this for approval, or should I start implementing?"), in plain language, with a recommendation. If unanswerable, state assumptions and give a provisional plan. Honour narrower scope: a single-subsystem request is not a whole-company audit; an unspecified workspace audit covers every first-party application, package and operational surface before selecting priorities.

Find the actual system

Read project guidance, manifests, lockfiles, configuration and existing architecture decisions. Record the baseline revision and dirty state without disturbing existing work. Declared, locked, installed and deployed versions can differ; say which you verified.

Build a coverage map: each application or package, its role, framework version, actual paradigm, runtime and evidence status. A multi-app workspace may legitimately use several paradigms. Trace representative flows end to end, including failure and asynchronous paths (entrypoints, auth, domain rules, persistence and tenancy, integrations, queues and retries, build and release, tests). A directory tree or search hit does not prove runtime behaviour. Use history, tests and owners to learn why a workaround exists; an unexplained one is "reason unknown", not "unnecessary".