docs: switch task management and wiki to gitea, merge to development only for non-release changes #7
@@ -6,7 +6,6 @@ This file is the authoritative source for hrynco-ef workflow, delivery, and role
|
||||
|
||||
- Command timeout: if a command runs longer than 10 minutes, report timeout and ask the user.
|
||||
- Validate required services before task work:
|
||||
- YouTrack authenticated access
|
||||
- Gitea authenticated access and the `hrynco/hrynco-ef` repo
|
||||
- TeamCity authenticated access
|
||||
- If any startup check fails, stop and ask the user.
|
||||
@@ -30,7 +29,6 @@ Print one startup report line per check:
|
||||
Required report items:
|
||||
|
||||
- Workflow rules loaded
|
||||
- YouTrack auth + reachability
|
||||
- Gitea auth + reachability
|
||||
- Gitea resource access (`hrynco/hrynco-ef`)
|
||||
- TeamCity auth + reachability
|
||||
@@ -47,7 +45,7 @@ Required report items:
|
||||
- local `development` must match remote
|
||||
- if not, fix that first
|
||||
- On task start:
|
||||
- set YouTrack state to `In Progress`
|
||||
- create a Gitea issue in `hrynco/hrynco-ef` if one does not exist
|
||||
- create a feature branch from `development`
|
||||
- name the branch after the task
|
||||
- Work only in the feature branch.
|
||||
@@ -56,12 +54,12 @@ Required report items:
|
||||
|
||||
### Issue lifecycle
|
||||
|
||||
1. Product analyst creates/refines the YouTrack task.
|
||||
2. Developer takes the task and starts implementation.
|
||||
1. Product analyst creates/refines the Gitea issue.
|
||||
2. Developer takes the issue and starts implementation.
|
||||
3. Developer finishes implementation and hands off to code review.
|
||||
4. Code reviewer reviews and either passes or returns to developer.
|
||||
5. Repeat developer/reviewer cycles as needed.
|
||||
6. Maximum five review rounds total for the same unresolved task state.
|
||||
6. Maximum five review rounds total for the same unresolved issue state.
|
||||
7. After review round five, if still unresolved, return to product analysis.
|
||||
8. Tester validates the implementation against acceptance criteria.
|
||||
9. Developer waits for user validation approval.
|
||||
@@ -69,7 +67,7 @@ Required report items:
|
||||
|
||||
### Task rules
|
||||
|
||||
- Create the YouTrack task before development starts.
|
||||
- Create the Gitea issue before development starts.
|
||||
- Default assignee is AI unless the task flow requires another assignee.
|
||||
- Define scope and acceptance criteria.
|
||||
- Tasks must be independently deliverable and testable.
|
||||
@@ -89,22 +87,17 @@ After explicit user validation approval:
|
||||
- push the feature branch
|
||||
- create PR from feature branch to `development`
|
||||
- merge that PR
|
||||
- create PR from `development` to `main`
|
||||
- merge that PR
|
||||
- wait for TC `HrynCo / HrynCo.EF / publish` to finish successfully
|
||||
- set the YouTrack task to `Done`
|
||||
- calculate exact Spent Time from YouTrack timestamps only
|
||||
- set the YouTrack Spent Time field
|
||||
- **do not merge to `main` unless a new NuGet package release is explicitly requested**
|
||||
- when a release is requested: create PR from `development` to `main`, merge, wait for TC `HrynCo / HrynCo.EF / publish` to finish successfully
|
||||
- close the Gitea issue
|
||||
- switch back to `development`
|
||||
- pull latest `development`
|
||||
- ensure local `development` and `main` match their remotes
|
||||
- ensure local `development` matches remote
|
||||
- leave the repository in a clean end state
|
||||
|
||||
### Spent Time
|
||||
|
||||
- Do not estimate or infer Spent Time.
|
||||
- Use exact YouTrack creation and Done timestamps only.
|
||||
- If exact timestamps are unavailable, stop and ask the user.
|
||||
- Do not track spent time — this repo uses Gitea, not YouTrack.
|
||||
|
||||
### Command output
|
||||
|
||||
@@ -115,9 +108,9 @@ After explicit user validation approval:
|
||||
|
||||
- Keep command output summaries concise.
|
||||
- Do not dump raw command output unless needed.
|
||||
- Use direct links in YouTrack and implementation notes when stable links exist.
|
||||
- Use direct links to Gitea issues and wiki pages in implementation notes when stable links exist.
|
||||
- Use emojis intentionally for scanning, not mechanically.
|
||||
- Commit messages must be Conventional Commit style, lowercase subject, short body, and final line `Ref: IT-<number>`.
|
||||
- Commit messages must be Conventional Commit style, lowercase subject, short body.
|
||||
|
||||
## 6. Audio
|
||||
|
||||
|
||||
@@ -202,6 +202,3 @@ services.AddScoped<IRepository<Product>, ProductRepository>();
|
||||
services.AddScoped<IUnitOfWork, EfUnitOfWork<YourDbContext>>();
|
||||
```
|
||||
|
||||
## Related
|
||||
|
||||
- [IT-642](https://yt.grynco.com.ua/issue/IT-642) — Extract `PagedResult` builder as reusable `IQueryable<T>` extension
|
||||
|
||||
Reference in New Issue
Block a user