THE GITHTML FIELD GUIDE
Review architecture boundaries from a phone without losing context
For a mobile architecture review, focus on boundaries rather than trying to inspect an entire codebase. Read the system purpose, component responsibilities, external dependencies, and one representative flow. Record questions against a specific revision, then defer conclusions that require detailed source inspection instead of treating a diagram as complete evidence.
Prepare a reviewable slice
Ask for a small HTML packet containing a context view, a responsibility list, and links to the relevant decisions. C4's context guidance supports starting with people and neighboring systems before internal detail. An illustrative review might ask whether export processing belongs to the API service or a worker. Keep that question visible at the top. A phone screen is suited to a narrow decision and supporting evidence, not a wall-sized deployment map. Include a text explanation for any visual whose labels become unreadable at ordinary zoom.
Check responsibility at each boundary
For the illustrative export design, identify who accepts the request, validates authorization, owns durable state, performs work, and reports failure. Ask whether two components both claim ownership of the same invariant or whether neither does. Examine the dependency direction and the consequence of an unavailable neighbor. A box labeled storage does not explain who deletes expired artifacts or who handles failed writes. Write each concern as a question with a source reference rather than declaring a design flaw from the summary alone.
- Ownership: identify the component responsible for each important invariant.
- Dependency: state what a caller assumes about the component it contacts.
- Failure: ask what users observe when the boundary does not respond as expected.
Leave an actionable review record
Capture the decision, evidence reviewed, unresolved question, and owner needed for follow-up. Separate a confirmed mismatch from a concern that requires more inspection. Do not approve a risky architectural change merely because the presentation is coherent. A useful mobile outcome may be a precise request for a missing data-flow explanation. gitHtml can display the committed HTML review packet; it does not inspect the repository or make architectural judgments automatically. Return to the exact source revision in your normal development tools before making implementation changes or granting final approval.
Sources and further reading
AI-assisted writing with source-linked guidance and illustrative examples. Read our editorial approach or report a correction.