refactor: Update .gitignore to remove kiro specs directory

[mfranzke]

Proposed changes

Remove /.kiro/specs/ from .gitignore.

Oftentimes our PRs lack a lot of information, up to not including any description at all. Besides fixing this, any information on the initial thoughts, concepts, requirements, design and todo/tasks are helpful to understand the development in the future and that for are a crucial and essential part of the documentation.

Checklist

Code Quality

• I have reviewed my own code (self-review)
• I have reviewed my changes locally with an AI assistant (e.g. GitHub Copilot, Kiro, etc.)
• No hardcoded values, magic numbers, or debug code left in

Validation

• I have added/updated tests that cover my changes
• I have tested across all relevant frameworks (React, Angular, Vue) if applicable

General

• The PR title follows the conventional commits format (e.g. feat:, fix:, chore:)
• If architecture, structure, or conventions changed inside a packages/* folder, the corresponding AGENTS.md has been updated

🔭🐙🐈 Test this branch here: https://design-system.deutschebahn.com/core-web/review/refactor-removing-kiro-specs-directory-from-gitignore

[Copilot]

Copilot wasn't able to review any files in this pull request.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 91b91a5

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[nmerget]

Before you commit some kiro related stuff please use Kiro somehow.

I think the spec files shouldn't be commited. Look at this example:

There are so many specs at the moment in my project, even now I'll don't have any overview about the specs. Also most of the older specs are outdated.

In the old world without AI, commiting a spec folder is the equvivalent of pushing a User Story to you codebase. We have other tools for this. If there is any desicion you want to save, we should make a steering that we save it in docs or adr etc. But this would be just a summary and it would be an overall architecture/documentation, not a single task

[mfranzke]

Before you commit some kiro related stuff please use Kiro somehow.

I think the spec files shouldn't be commited. Look at this example:

There are so many specs at the moment in my project, even now I'll don't have any overview about the specs. Also most of the older specs are outdated.

In the old world without AI, commiting a spec folder is the equvivalent of pushing a User Story to you codebase. We have other tools for this. If there is any desicion you want to save, we should make a steering that we save it in docs or adr etc. But this would be just a summary and it would be an overall architecture/documentation, not a single task

I have not just used Kiro, but even also been in a workshop for using Kiro hold by Amazon. If we could somehow save the information out of these files differently, that's fine, but if all of those are lost and our PRs remain mostly undocumented, we do have a problem with missing documentation.