36 lines
3.5 KiB
Markdown
36 lines
3.5 KiB
Markdown
# Repository Guidelines
|
|
|
|
## Project Structure & Module Organization
|
|
|
|
The solution `LIAM.sln` covers all Matrix42 integration projects. Runtime code centers on `LiamM42WebApi` (service endpoints), `LiamWorkflowActivities*` (workflow logic and designers), and adapters such as `LiamActiveDirectory`, `LiamExchange`, and `LiamMsTeams`. Shared helpers live in `LiamBaseClasses` and `LiamHelper`. The `_shared` directory pins required third-party binaries; do not modify or rename them. NuGet restore artifacts belong in `packages/`, and the WinForms tooling `LiamTestTeams` supports manual verification.
|
|
|
|
## Build, Test, and Development Commands
|
|
|
|
Run `nuget restore LIAM.sln` once per clone to hydrate packages. Build locally with `msbuild LIAM.sln /p:Configuration=Debug`; use `Release` for deployable artifacts. For a clean rebuild, execute `msbuild LIAM.sln /t:Clean,Build /p:Configuration=Debug`. Visual Studio can open `LIAM.sln`, with `LiamM42WebApi` as the suggested startup project. When self-hosting the API, deploy it to IIS or IIS Express pointing at the project folder.
|
|
|
|
## Coding Style & Naming Conventions
|
|
|
|
Follow C# Allman braces with four-space indentation. Maintain `PascalCase` for classes, members, and constants (e.g., `constFragmentNameConfigProviderBase`), and `camelCase` for locals and parameters. Keep `using` directives sorted and trimmed. New projects should link `SharedAssemblyInfo.cs` to align assembly metadata. Format via Visual Studio or `dotnet format` if the SDK is available.
|
|
|
|
## Testing Guidelines
|
|
|
|
Automated tests are currently absent; regression work relies on targeted manual runs. Use `LiamTestTeams` to drive Microsoft Teams scenarios and validate API calls. Document manual steps in pull requests until automated coverage is added. When introducing tests, co-locate them with the feature project and add the project to `LIAM.sln` so CI can call the standard `msbuild` targets.
|
|
|
|
## Commit & Pull Request Guidelines
|
|
|
|
History is minimal (`initial`), so prefer concise, imperative commit subjects and reference tracking IDs when applicable (e.g., `Add Graph delta sync for users (LIAM-123)`). Squash tooling-only commits before merge. Pull requests should note the impacted integration area, configuration changes, and manual verification evidence (logs, screenshots, or request IDs). Confirm no secrets are included and request review from the owner of each touched module.
|
|
|
|
### Mandatory Workflow Rules
|
|
|
|
- Before starting any request that requires a code change, the repository must have no open Git changes (`git status --short` must be empty).
|
|
- If the working tree is not clean before starting a code change request, stop and clarify with the requester before proceeding.
|
|
- After completing a requested code change, always create a Git commit with a concise, fitting, imperative message.
|
|
- After completing a requested code change, always push the new commit immediately to the configured remote branch.
|
|
- If a `git push` fails, retry the push up to 5 times with a short delay between attempts before reporting the failure.
|
|
- Use Windows line endings (`CRLF`) for all text files in this repository.
|
|
- Every newly created or modified text file must be written back with Windows line endings (`CRLF`).
|
|
|
|
## Security & Configuration Tips
|
|
|
|
Exclude environment-specific `web.config`, `app.config`, and credential artifacts from version control. Treat binaries under `_shared` as read-only dependencies. When updating external references, confirm compatibility with the target Matrix42 environment and record the expected deployment steps in the PR.***
|