36 lines
2.5 KiB
Markdown
36 lines
2.5 KiB
Markdown
# Repository Guidelines
|
||
|
||
## Project Structure & Scope
|
||
|
||
This repository is an evidence bundle for HarmonyOS futures-app freeze and OOM remediation; it does not contain buildable application source code.
|
||
|
||
- `harmony-ths-futures-freeze/doc/change-notes/` contains freeze/performance remediation notes, numbered `01`–`11`.
|
||
- `harmony-ths-futures-apm-oom/doc/change-notes/` contains memory-retention remediation notes, numbered `10`–`15`.
|
||
- `change-notes.zip` is the distributable archive of those two directories. Keep it synchronized only when a deliverable archive is requested.
|
||
|
||
Treat notes as technical records: distinguish changes made in the app, communication HAR, and trade SDK repositories, and do not imply that an upstream change is present here.
|
||
|
||
## Documentation Style & Naming
|
||
|
||
Write Markdown in Chinese, matching the existing material. Use direct `#` and `##` headings and concise paragraphs. New notes should follow the established numbered, kebab-case pattern, for example `12-new-memory-audit.md`.
|
||
|
||
Use fenced code blocks for commands and backticks for paths, module names, APIs, package versions, branches, and commit IDs. Preserve exact measurements, units, dates, device details, and command output; identify estimates and limitations explicitly. Prefer tables for baseline-versus-result comparisons.
|
||
|
||
## Validation and Development Commands
|
||
|
||
There is no local build, formatter, linter, or test suite. Do not run application builds from this repository. Record validation performed in the relevant upstream HarmonyOS checkout, for example:
|
||
|
||
```sh
|
||
devecocli build --modules entry@default
|
||
devecocli check lint
|
||
devecocli log --crash --bundle-name <bundle-id>
|
||
```
|
||
|
||
State whether each command was actually run, its target (module/device), and any skipped coverage. Do not present a suggested command as a completed verification.
|
||
|
||
## Change Notes and Review
|
||
|
||
Each remediation note should include: the fix commit(s) and branch(es), problem statement, changed scope, implementation/mitigation, behavior and risk boundaries, and concrete verification results. Keep unrelated cleanup and temporary test artifacts out of documented production changes.
|
||
|
||
This bundle has no Git metadata, so no local commit-message convention can be inferred. Use a short imperative subject such as `docs: add table request cleanup note`. Pull requests should name the affected upstream repository and commit, link the incident or ticket when available, and include before/after metrics or screenshots/log excerpts for behavior claims.
|