Bump RFC — Incan Project

Overview

RFCs move through four statuses. Each transition requires specific file edits, GitHub actions, and prerequisites.

Status	Meaning
Draft	Design and/or review in flight (may have open questions, or none while awaiting review before Planned)
Planned	Design settled; ready for implementation
In Progress	Active implementation underway
Implemented	Implementation complete and included in a merge-ready PR, or already shipped

Read the RFC's current Status: field, then follow the matching section below.

---

Draft → Planned

Prerequisites

All answered: nothing open under ## Unresolved questions; settled record under ## Design Decisions (see review-rfc → Planned+ rule). No fake questions.

Before bumping, verify:

• No open bullets under ## Unresolved questions (if present). No disguised open items under Design Decisions.
• At least one review round has been completed (use /review-rfc if not done).
• GitHub issue exists and is linked in the RFC header.
• User has confirmed the bump (ask if unclear).
• Discuss any open design decisions with the user.

File changes

Outcome: Planned+ rule — no ## Unresolved questions; tail is ## Design Decisions only.

1. Both ## Design Decisions and ## Unresolved questions: merge remainder into Design Decisions, drop ## Unresolved questions.
2. Only ## Unresolved questions: rename → ## Design Decisions.
3. Only ## Design Decisions: leave as-is.
4. Strip EOF <!-- Rename this section to "Design Decisions"... --> if present.
5. Status: Draft → Status: Planned.

GitHub actions

# Remove RFC label, add feature label
gh api repos/dannys-code-corner/incan/issues/<NNN>/labels/RFC -X DELETE
gh api repos/dannys-code-corner/incan/issues/<NNN>/labels -X POST --input - <<'EOF'
{"labels":["feature"]}
EOF

# Post a status comment
gh issue comment <NNN> --repo dannys-code-corner/incan --body \
  "RFC has moved to **Planned** status. Design is settled; implementation can begin."

---

Planned → In Progress

Prerequisites

• At least one implementation PR has been opened or a contributor has picked up the work.
• User has confirmed the bump.

File changes

When an implementation PR exists, record its link in RFC PR and retain other implementation PR links. If work has started without an implementation PR, leave RFC PR as — until one is opened. Never use a proposal or documentation-only PR for this field.

After the ## Layers affected section, add two new sections: ## Implementation Plan and ## Progress Checklist.

## Implementation Plan — concrete phases, not internal file paths. Model after the RFC's "Layers affected" section, but task-oriented. Example shape:

## Implementation Plan

### Phase 1: Parser + AST

- Add syntax support for `<new construct>` in the lexer and parser.
- Extend the AST to represent `<new construct>` as a typed node.
- Add formatter support for the new syntax.

### Phase 2: Typechecker

- Validate `<new construct>` at declaration sites.
- Resolve references in expression positions.
- Emit span-precise diagnostics for invalid usage.

### Phase 3: Lowering + Emission

- Lower `<new construct>` to the IR representation.
- Emit correct Rust code for all cases.

### Phase 4: Stdlib + Tests

- Add stdlib declarations (if applicable).
- Add parser, typechecker, codegen snapshot, and integration tests.
- Update docs.

## Progress Checklist — fine-grained - [ ] items, grouped by area. These will be ticked as PRs land. Example shape:

## Progress Checklist

### Spec / design

- [ ] Lock down edge cases for `<X>` and add to "Design Decisions".

### Parser / AST

- [ ] Lexer: emit new token for `<keyword>`.
- [ ] Parser: parse `<construct>` in declaration/expression position.
- [ ] AST: represent as `<NodeKind>` with correct span.
- [ ] Formatter: round-trip `<construct>` stably.

### Typechecker

- [ ] Validate at declaration sites.
- [ ] Resolve in expression positions.
- [ ] Error: `<diagnostic name>` for invalid usage.

### Lowering / IR

- [ ] Lower `<construct>` to `<IrNode>`.

### Emission

- [ ] Emit correct Rust for `<construct>`.

### Stdlib / Runtime

- [ ] Declare in `stdlib/<module>.incn` (if applicable).
- [ ] Wire Rust backing type in the owning component's facet, `loaves/stdlib/<component>/rust/` (if applicable).

### Tests

- [ ] Parser unit test for `<construct>`.
- [ ] Typechecker unit test: valid usage.
- [ ] Typechecker unit test: invalid usage → correct diagnostic.
- [ ] Codegen snapshot test: `<construct>` in expression position.
- [ ] Integration test (end-to-end compile + run).

### Docs

- [ ] Update relevant docs-site pages.
- [ ] Add release notes entry.

3. Update the header: Status: Planned → Status: In Progress.

GitHub actions

Post the implementation plan to the GitHub issue so contributors can track it there too:

gh issue comment <NNN> --repo dannys-code-corner/incan --body \
  "RFC has moved to **In Progress**. Implementation plan added to the RFC document and pasted below for reference.

<paste the Implementation Plan + Checklist content here>"

---

In Progress → Implemented

Prerequisites

• All - [ ] items in the Progress Checklist are - [x].
• Implementation is complete and covered by a merge-ready PR, or already merged to main.
• Required local and/or CI verification has passed for the implementation PR.
• Release version is known.
• User has confirmed the bump.

File changes

1. Update the header: Status: In Progress → Status: Implemented.
2. Fill the release field with the actual Incan release version:
   • If the RFC uses Shipped in:, set Shipped in: vX.Y.
   • If the RFC uses Implemented version:, set Implemented version: X.Y.Z.
3. Move the RFC document into workspaces/docs-site/docs/RFCs/closed/implemented/ and keep the same filename.
4. Optionally rename ## Progress Checklist → ## Implementation log to signal it is historical rather than active.

GitHub actions

Ensure the implementation PR body includes a closing keyword for the issue, for example Closes #<NNN>. Do not manually close the issue as part of the RFC bump; the PR merge should close it.

Optionally post a traceability comment while the PR is still open:

gh issue comment <NNN> --repo dannys-code-corner/incan --body \
  "RFC has moved to **Implemented** in the implementation PR. Implementation is complete and targeted for vX.Y; the issue will close when the PR merges."

Release notes

Add an entry to workspaces/docs-site/docs/release_notes/<vX_Y>.md following the project's release notes style:

- **<Area>**: <One-line description of the feature> (RFC NNN, #<issue>)

---

Quick reference

From	To	Key file change	Key GitHub action
Draft	Planned	Planned+ rule (File changes above); update Status	Relabel RFC → feature
Planned	In Progress	Add Implementation Plan + Progress Checklist; update Status	Post plan as issue comment
In Progress	Implemented	Update Status; fill release field; move file to closed/implemented/; optionally rename checklist to log	Ensure PR closes issue; optional traceability comment