docs: add Contributor Implementation Guide (closes #43) - #162
Open
dokiromboide wants to merge 1 commit into
Open
docs: add Contributor Implementation Guide (closes #43)#162dokiromboide wants to merge 1 commit into
dokiromboide wants to merge 1 commit into
Conversation
- New guide at docs/contributor-implementation-guide.md covering mental model, implementation workflow, edge cases, security/compliance assumptions, docs/readme, acceptance checklist, and PR opening process - Link guide from README.md (Guides section) and CONTRIBUTING.md (Guides section) - All tests pass (117/117) and npm run check passes Closes #43
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes issue #43
I added docs/contributor-implementation-guide.md because the existing docs explain process and review policy, but not what an actual SDK change looks like from start to finish.
The guide walks through the boundaries that matter in this repo: from app code, then AegisClient then Soroban contracts, finally dashboard. From there it covers designing typed interfaces, wiring a module into the client, covering edge cases, and documenting assumptions that affect compliance behavior. I also linked it from README.md and CONTRIBUTING.md.
This PR is only documentation, no runtime code, types, fixtures, or tests changed, so the existing suites are still the right verification surface.